Tag: Zimbra

Un serveur mail Zimbra familial

Aucun commentaire sur Un serveur mail Zimbra familial

15 septembre 2010 at 17 h 51 minCategorie :Zimbra

Zimbra, le groupware open-source, est un outil de messagerie extrêmement puissant, principalement destiné aux entreprises ou aux grosses associations.
En connaissant cette orientation, lorsqu’on décide de s’installer son propre serveur de mail personnel , Zimbra n’est évidemment pas le premier nom qui vient à l’esprit. On pense plus naturellement à quelque chose comme Roundcube, en conjonction avec divers backend comme le vénérable Postfix et le sympathique Dovecot, ce qui semble bien plus simple et plus adapté à un usage familial.

Et pourtant, après quelque essais, je pense maintenant que Zimbra a parfaitement sa place dans le cercle privé.  Ce n’est pas parce qu’on est un particulier qu’on n’a pas l’usage d’outils avancés de partage de documents, de messagerie instantané, ou de synchronisation avec des clients mobiles. De même, pourquoi ne pas bénéficier du support de qualité offert par une société aux reins solides (d’autant plus après son rachat par Yahoo puis VMware), avec tout ce que cela implique en termes de mises à jours, de suivi, et de pérennité.

Et contrairement aux idées reçues, il est parfois plus simple d’installer un énorme logiciel (que certains qualifieraient à tort d’usine à gaz), que de se battre à intégrer différents petits composants les uns avec les autres. Bien sûr le coté formateur d’une telle installation composite est très appréciable. Mais pour ma part j’ai déjà donné (venu, vu, appris, et passé à la dimension supérieure), et j’apprécie dorénavant de ne lancer qu’un seul script pour installer la dernière version de mon MTA, de Amavis, de l’indispensable SpamAssassin, du serveur IMAP sécurisé, tout en récupérant plein de nouveautés pour la très pratique interface web (et je passe d’autres composants tout aussi indispensable).

Voilà, c’est pour toutes ces raisons que j’ai installé un serveur Zimbra pour mon usage personnel (et familial in extensio, ce serait dommage de garder un tel outil pour soi). Cela n’est pas allé sans quelque gymnastique, bien entendu… Et voilà pourquoi vous lisez cet article : profitez de mes quelques notes, qui je l’espère serviront à d’autres dans l’établissement de leur propre serveur de mail personnel.

Zimbra à travers un Apache déjà existant

Zimbra vient avec son propre serveur HTTP.
Cependant, il est fréquent pour un serveur personnel, d’avoir déjà un LAMP ou autre, qui héberge divers sites ou service. Il est donc plus pratique de garder son propre Apache sur le port standard 80, et de mettre Zimbra sur un autre port (c’est faisable depuis l’interface d’administration qui elle est accessible sur le port 7071 en HTTPS. Dans cet exemple j’ai 82 en HTTP et 445 en HTTPS)
Tout d’abord, chercher sur internet selon votre distribution, il vous faut installer et activer mod_proxy.
Ensuite je pars du principe que vous utiliser les VirtualHost, tant ceux ci sont pratiques.

<VirtualHost *:80>
    ServerName <nom_hote_virtuel>
    ServerAlias <autrenom>
    # Très important pour ne pas transformer votre serveur en open proxy !
    ProxyRequests Off
    # Le proxypass permet de transférer la requête à un autre serveur
    ProxyPass / http://<hote_reel_serveur_zimbra>:82/
    # Le proxypassreverse permet de réécrire les pages html afin
    #de faire pointer les liens à vers l'hôte virtuel et non
    # pas vers le nom d'hôte / port réel.
    ProxyPassReverse / http://<hote_reel_serveur_zimbra>:82/
    <Location "/">
        Order deny,allow
        Allow from all
    </Location>
</VirtualHost>
<IfModule mod_ssl.c>
<VirtualHost *:443>
    DocumentRoot "/var/www/"
    ServerName <server>
    ServerAlias <autrenom>
    # n'oubliez pas de configurer vous même selon l'emplacement de vos certificats
    SSLEngine on
    SSLCertificateFile <chemin>/server.crt
    SSLCertificateKeyFile <chemin>/server.key
    ProxyRequests Off
    SSLProxyEngine on
    ProxyPass / https://<hote_reel_serveur_zimbra>:445/
    ProxyPassReverse / https://<hote_reel_serveur_zimbra>:445/
    <Location "/">
        Order Deny,Allow
        Allow from all
        BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown
    </Location>
</VirtualHost>
</IfModule>

Gérer le spam

Une de mes premières actions a été d’empêcher la suppression du spam. Bien que SpamAssassin soit très efficace, il faut peupler sa base heuristique avant qu’il ne soit capable de trier le bon grain de l’ivraie. En attendant, il est donc sage de réduire à zéro le nombre de spam supprimé, en permettant tout de même le déplacement dans le dossier spam de votre boite mail en  cas de doute.
Ceci se fait depuis l’interface d’administration (paramètres globaux, onglet AS/AV)

Un petit bonus : si le nom de domaine que vous utilisez n’est pas le même que le nom d’hôte de la machine, alors il est possible que vos comptes spams ne soient plus vraiment cohérents avec votre installation. Pour définir de nouveaux comptes spam, vous pouvez passer ces commandes avec l’utilisateur zimbra :

zmprov mcf zimbraSpamIsSpamAccount <adressemailspam>@domain.com
zmprov mcf zimbraSpamIsNotSpamAccount <adresseemailPASspam>@domain.com

Si vous êtes vicieux, laissez trainer l’adresse de spam partout sur Internet. Vous aurez un magnifique pot à miel pour peupler votre base de données à peu de frais.

Optimiser les ressources consommées par Zimbra

Zimbra est très demandeur de ressources, aussi bien CPU que mémoire. En cause : les très nombreux processus d’arrière plan comme par exemple l’indexation, ou encore pour « troller » un peu, le choix du Java. Si votre Zimbra n’est pas très sollicité, alors autant limiter ses ressources dès le départ afin qu’il n’empiète pas sur d’autres services temps réel de votre machine (serveur vocal, etc.)

On commence par un renice régulier des processus de zimbra dans la crontab. Ceci est nécessaire car les processus disparaissent et sont relancés très fréquemment :

*/5 * * * * renice 19 -u zimbra > /dev/null

Pour limiter le nombre de thread disponibles pour les clients, utilisez ces commandes :

zmprov ms this.server.name zimbraHttpNumThreads 50
zmprov ms this.server.name zimbraPop3NumThreads 5
zmprov ms this.server.name zimbraImapNumThreads 10

Pour info, vous pouvez utiliser « zmprov gs » pour récupérer les valeurs actuelles, ce qui vous permettra de vous rendre compte qu’elles sont réellement trop élevées pour une utilisation personnelle.

Passons à la mémoire. Lancez cette commande :

zmlocalconfig mailboxd_java_heap_memory_percent

Vous voyez en lisant le résultat que Zimbra consomme de la mémoire en fonction du total disponible sur votre machine. Plus vous en avez, plus Zimbra va en prendre. C’est pratique, mais ces valeurs sont encore une fois trop importantes pour un faible nombre d’utilisateurs. Pourquoi ne pas les modifier à la baisse? :

zmlocalconfig -e mailboxd_java_heap_memory_percent=25
# Le serveur embarqué mysql fonctionne
# sur le même principe : sabrons le lui aussi !
zmlocalconfig -e mysql_memory_percent=20

Si vous avez comme moi installé le package Debian sur Ubuntu , car la version finale pour votre distribution préférée tardait trop à venir, vous avez peut être un bug qui conduit à une indisponibilité de l’application au bout de quelques heures. Dans ce cas voici un moyen d’éliminer ce bug en gérant les ressources manuellement :

zmlocalconfig -e ldap_read_timeout=0
zmlocalconfig -e ldap_connect_timeout=0

Ensuite éditez /opt/zimbra/jetty/etc/jetty-setuid.xml et mettez la limite de filedescriptor a 524288.
Editez /etc/security/limits.conf  et ajoutez ceci :

root soft nofile 524288
root hard nofile 524288

Empêcher l’open relay SMTP mais permettre les envois locaux

Un vrai danger pour votre machine ! Si celle ci est configurée en open relay, alors toutes machines connectées à internet peut se servir de votre serveur pour envoyer des spams.  Les conséquences sont dramatiques, avec en tête une surconsommation de ressources, et un rapide référencement sur les listes RBL, ce qui conduira votre serveur à être blacklisté par tous les grands services mail destinataires.
Par défaut Zimbra est configuré de façon à empêcher l’open relay. Cependant cela peut être trop restrictif, et vous pouvez avoir besoin de permettre à des services de votre machine d’envoyer des mails par eux mêmes. Pour cela mettez en liste blanche les adresses locales :

mprov modifyServer zimbra.example.com zimbraMtaMyNetworks '127.0.0.0/8 XXX.XX.X.X/32'

Activer le pooling automatique des adresses externes

Afin de d’optimiser l’utilisation de votre nouveau serveur, vous allez certainement configurer une récupération automatique des mails sur votre ancienne adresse. Heureusement, la quasi totalité des fournisseurs permet d’utiliser le protocole POP, ce qui nous permet facilement d’atteindre cet objectif.
Par défaut, pour économiser des ressources dans les environnements avec beaucoup d’utilisateurs, cette récupération de mail externe ne se fait que sur demande de l’utilisateur. Dans le cas d’un serveur familial, le surcoût engendré par un pooling automatique est minime comparé aux avantages ergonomiques. Tout d’abord :

zmprov mc default zimbraDataSourcePop3PollingInterval 10m

Si ça ne suffit pas (notamment pour les comptes externes déjà créés qui risquent de ne pas prendre en compte la modification), effectuez la configuration au niveau de l’utilisateur :

zmprov ma user@domain.com zimbraDataSourcePollingInterval 5m

Ou enfin pour être bien sur, faites le au niveau du compte externe :

zmprov mds user@domain.com [external IMAP/POP account data source name] zimbraDataSourcePollingInterval 15m

Pour récupérer les noms des comptes externes, utilisez cette commande :

zmprov gds user@domain.com

Pour tout annuler, remettez à zéro les valeurs.

Conclusion

Je vais faire court : Si vous avez d’autres astuces, direction les commentaires !

Une sauvegarde FTP ordonnancée et simple, appliquée à Zimbra

Un commentaire sur Une sauvegarde FTP ordonnancée et simple, appliquée à Zimbra

16 août 2010 at 21 h 54 minCategorie :Zimbra

En informatique, rien n’est plus vrai que l’adage « un script qui peut le plus peut le moins ».
A ceci, j’aime rajouter son corollaire :  » un script qui peut le plus coûte cher et est relou à maintenir « …

Tout l’art consiste à choisir son camp en fonction des circonstances… Vous vous en doutez sans doute, mais là c’est le moment idéal pour placer un exemple de script rapide et fonctionnel, et je ne vais pas me gêner.

J’ai eu besoin récemment de programmer une sauvegarde régulière de l’ensemble du Zimbra que j’héberge pour usage familial. Pourquoi une sauvegarde? Il ne s’agit pas d’un environnement professionnel à haute criticité, alors à quoi bon s’embêter? Hum, bien sûr mon ami, mais je pense que tu ne t’es jamais retrouvé en face de membres de ta famille gémissant sur des mails perdus avec les photos du petit dernier. Lorsque le faciès de ta honte sera éternellement gravé dans les mémoires, tu regretteras de ne pas avoir prévu le crash du disque dur chez l’hébergeur.

Hop, voilà donc petit script pour exploiter l’espace FTP gracieusement mis à disposition à cet effet par mon hébergeur OVH et t’éviter une disgrâce familiale. Au menu :

– Rotation très poussée et configurable. Haha je plaisante, le but c’est de faire un script ultra simple.  On se contente de move et de del
– Utilisation de deux rsync avant le tar pour faire une longue sauvegarde à chaud puis une courte à froid pour minimiser le temps d’indisponibilité. NB: rsync et tar ont l’avantage de conserver les liens symboliques tels quels, contrairement à un simple cp.
– Dépôt FTP automatisé…
…Et c’est tout ! En effet Zimbra, même dans sa version communautaire, est plutôt simple à sauvegarder. Donc pas la peine de s’embêter avec des tonnes d’options.

Le voilà dans sa plus simple expression :

#!/bin/bash
SERVER=<serveur>
USERNAME=<login_ftp>
PASSWORD=<pwd_ftp>
DESTINATION=<chemin_destination> #chemin temporaire de travail pour faire les synchronisations et construire l'archive

function ftpfile {
   ftp -n <<EOF
   open $SERVER
   user $USERNAME $PASSWORD
   bin
   $1 $2 $3
   bye
   EOF
}

rsync -av --delete /opt/zimbra $DESTINATION
#/etc/init.d/zimbra stop
#rsync -av --delete /opt/zimbra $DESTINATION
#/etc/init.d/zimbra start
cd $DESTINATION
tar cvfz zimbra.tar.gz zimbra

ftpfile del zimbra.tar.gz.3
ftpfile rename zimbra.tar.gz.2 zimbra.tar.gz.3
ftpfile rename zimbra.tar.gz.1 zimbra.tar.gz.2
ftpfile rename zimbra.tar.gz zimbra.tar.gz.1
ftpfile put zimbra.tar.gz

Le script est à exécuter en tant que root (nécessaire pour conserver les propriétaires des fichiers).
Et on n’oubliera pas d’ajouter  une ligne idiote dans la crontab. Je ne vous fait pas l’affront de l’écrire à votre place, mais je me permets deux petits conseils :
– redirigez la sortie standard de votre opération de « tar » quelque part.
– mentionnez expressément l’interpréteur en tête de votre commande dans la ligne cron.
Pourquoi? Personne ne semble capable de l’expliquer, mais parfois le tar s’interrompt en plein milieu si  ceci n’est pas rajouté (j’ai pu le constater, avec beaucoup d’étonnement d’ailleurs). Ce qui donne par exemple :

0 3 * * *  /bin/bash <chemin>/sauvegarde.sh > /var/log/sauvegarde.log

Bonus : comment restaurer la sauvegarde

Rien de plus simple. Remplacer le répertoire /opt/zimbra par le contenu de votre tar.
S’il s’agit d’une nouvelle machine parce que l’impitoyable crash de votre disque dur à été total, n’oubliez pas de réinstaller la même version de Zimbra par la procédure standard avant d’extraire le tar. En effet les paquets doivent être proprement installés au moins une fois.