Le moteur Blackhole et la réplication

Dans un système à forte charge il est fréquent de trouver plusieurs serveurs MySQL synchronisés entre eux via la réplication des données. Toutes les données ajoutées sur le serveur Maître sont sont enregistrées dans un journal qui est alors envoyé sur les différents serveurs Esclave pour y être joué afin que les bases soient parfaitement synchronisées. Etant donné que le journal contient les ordres sql, les serveurs MySQL peuvent fonctionner avec différents moteurs de stockage.

Utilisation en Proxy

Si les tables sur le Maître utilisent le moteur Blackhole, alors celui-ci ne fait qu’enregistrer les ordres SQL et les transmet aux différents serveurs Esclave. Bien entendu, seulement une ou une partie des tables peuvent être configurées de cette manière afin de répartir la charge entre différents serveurs dans le cas de grosses charges en écriture.

Utilisation en filtre de réplication

Un des inconvénients de la réplication MySQL actuelle, c’est qu’elle ne permet pas de de ne répliquer qu’une partie des données présentes sur le Maître. Ainsi, si un Maitre possède beaucoup de données, les Esclaves sont en principe obligés de supporter la même volumétrie même si ces données ne sont pas utilisées. Comme les tables sur un Esclave peuvent ne pas utiliser le même moteur de stockage que sur le Master, il est possible de déclarer les tables sur l’Esclave avec un moteur Blackhole. Ainsi, lorsque le processus de réplication jouera les ordres SQL reçus du Maître, celle-ci seront jouées, mais sans aucune conséquence ni sur les accès disque ni sur la charge CPU du serveur.

Exemple

Vous gérez plusieurs serveur MySQL en réplication avec une grosse base de données et beaucoup de requêtes… Malheureusement, vous devez exécuter des requêtes très consommatrices d’accès disque et qui ne sont pas optimisables, du genre :

SELECT id FROM users WHERE name like '%dupont%';

Cette requête fera inlassablement un « Full scan » de la table et ne peut pas utiliser d’index. Si la table contient beaucoup d’enregistrements et/ou un certain volume de données, il sera très difficile d’obtenir des temps de réponse corrects. En prime, les autres requêtes seront ralenties.

Une solution ? Ajoutez un serveur Esclave, mais déclarez toutes les autres tables en Blackhole et réservez ce serveur à l’exécution de ces mauvaises requêtes. La réplication n’utilisera que très peu d’accès disque qui seront quasiment dédiés à ces mauvaises requêtes.

Un solution « riche » ? Si votre serveur a suffisamment de mémoire, déclarez une table Memory qui ne contiendra que ce champ « name » ou les champs nécessaires à vos requetes, et positionnez un trigger sur la table d’origine afin que les modifications apportées par la réplication soient répliquées dans la table en mémoire.

Quelques chiffres

Chez Wikio, nous avons mis en place cette solution pour faire une test avec une table qui occupe 1Go sur disque. Les temps de réponse sont les suivants :

• Sur une esclave non dédié : entre 10 et 30 secondes suivant la charge occasionnée par les autres requêtes
• Sur un esclave ne répliquant que les tables nécessaires : 9 secondes
• En mettant les tables en mémoire : 3 secondes

Ben sûr, vous me direz, la solution est coûteuse… mais dans certains cas, il est préférable de monopoliser un serveur afin que les traitements aillent 3 fois plus vite !

Pour mon usage, c’est l’utilisation de la téléphonie à partir de mon PC qui m’intéressait. Pouvoir téléphoner depuis mon PC, avec mon casque/micro (donc avec un certain confort d’utilisation) et au tarif de la téléphonie Free, c’est à dire gratuitement pour l’usage que j’en fait. En prime, ça permet de téléphoner sans occuper la ligne téléphonique !

Pour une simplicité de fonctionnement, il est préférable de configurer la Freebox en mode routeur afin qu’elle gère elle-même les ouvertures de ports nécessaires au fonctionnement de SIP.

1ère étape : Activer SIP dans son interface de gestion Free

Activer SIP depuis l'interface de gestion Free

2ème étape : Télécharger un logiciel de téléphonie

Vous pouvez par exemple télécharger SIPInside ou encore X-Lite. Le premier a l’avantage de fonctionner immédiatement avec Free (vous n’autrez juste qu’à indiquer votre compte). J’ai par contre eu des problèmes de sons avec celui-ci. X-Lite est plus complet (ou complexe ?) mais présente l’avantage de fonctionner sur d’autres plateformes que Windows.

Voici par exemple une copie du paramétrage de X-Lite :

Configuration de X-Lite pour mon compte Free

J’ai eu l’occasion de tester ce dispositif lors de conférences téléphoniques qui ont duré plus d’une heure. Je n’ai eu aucun problème de qualité de ligne ou de son.

Cela faisait un moment que je devais tester cette distribution. Xavier en est un fidèle utilisateur. Une mise à jour qui se passe mal sur mon ancien système… et me voilà donc parti à télécharger la dernière version de LinuxMint afin de faire le grand saut.
Verdict après l’installation : Bluffant. Certes, une des nouvelles fonctionnalités est le support amélioré des systèmes à double écrans par Gnome, mais je crois bien que c’est la première fois que tout s’installe automatiquement

Verdict après une journée d’utilisation : Tout marche bien. Malgré le passage à Gnome, je retrouve mes principaux outils et je n’ai pas rencontré de soucis particuliers. L’outil d’installation des packages est vraiment simple à utiliser et l’outil de mise à jour est prometteur (je ne l’ai pas encore véritablement testé). Un petit bémol pour la version d’Eclipse qui est la 3.2 alors que la 3.4 est dispo depuis un moment déjà.

Bref, si vous avez envie d’essayer cette distribution, n’hésitez pas. Elle existe également en version KDE (RC actuellement).

Heureusement, les derniers JDK proposent des outils plus ou moins ergonomiques afin de surveiller et mieux comprendre ce qu’il se passe. Avant toute chose, voici un (très) bref rappel du fonctionnement de la gestion de la mémoire Java et de son « garbage collector » (ou GC).

Java et le « garbage collector »

Afin d’optimiser le fonctionnement du GC, Java utilise par défaut un système mettant en oeuvre plusieurs zones mémoire. Ces zones sont utilisées par les objets plus ou moins vieux. Je ne rentrerai pas dans les détails de ces zones ni comment les dimensionner. Le GC utilise 3 zones au fur et à mesure que les objets vieillisent :

- Survivor space : Il est en fait séparé en 2. Chaque zone est active alternativement. Les objets nouvellement créés sont créés dans la zone active. Au moment du passage du YGC (Young Garbage Collector), celui-ci va nettoyer le Survivor Space en recopiant les objets encore référencés dans la seconde zone qui devient active à son tour. Au bout d’un certain nombre d’allez-retour, les objets sont alors transférés dans le « Eden space ».

- Young Space : Comme nous venons de le voir cette zone reçoit les objets encore jeunes qui ont survécus à plusieurs YGC.

- Old Space : Lorsque la place vient à manquer dans le Young Space, un Full Garbage Collector (FGC) est lancé et les objets les plus anciens de la Young Zone sont transférés dans cette zone.

En plus de ces 3 zones, il existe le Permanent Space qui comme son nom l’indique est utilisé pour le cache du code et les objets statiques.

Lorsqu’un problème de mémoire arrive, c’est en général car des objets restent référencés (par une liste ou autre) et finissent donc par remplir le Old Space. Un des premiers outils bien pratique pour suivre ces mouvements de mémoire entre les zones est jstat qui est livré avec le JDK. Différentes options existent, mais la surveillance du Garbage Collector est sans doute le plus intéressant dans notre cas.

jstat -gc -h10 <pid> 5s

 S0C    S1C    S0U    S1U      EC       EU        OC         OU       PC     PU    YGC     YGCT    FGC    FGCT     GCT
5376.0 10944.0 5319.5  0.0   723712.0 393938.3  571776.0   548046.1  61568.0 58080.5    754   27.767  26     16.290   44.057
9600.0 6976.0  0.0   6964.5 691648.0 232030.5  571776.0   550188.2  61568.0 58084.8    755   27.801  26     16.290   44.091
5504.0 10560.0 5465.1  0.0   777088.0 106216.4  571776.0   553407.3  61568.0 58085.2    756   27.870  26     16.290   44.161
5504.0 10560.0 5465.1  0.0   777088.0 608730.8  571776.0   553407.3  61568.0 58085.7    756   27.870  26     16.290   44.161
9856.0 5824.0  0.0   5801.2 865984.0 263527.0  571776.0   555880.7  61568.0 58086.1    757   27.892  26     16.290   44.182
9856.0 5824.0  0.0   5801.2 865984.0 696381.0  571776.0   555880.7  61568.0 58088.1    757   27.892  26     16.290   44.182
8192.0 10496.0 8180.9  0.0   826944.0 359223.6  571776.0   558621.8  61568.0 58088.4    758   27.910  26     16.290   44.201
7552.0 5312.0  0.0   5296.1 789824.0 71320.0   571776.0   563405.1  61568.0 58088.9    759   27.963  26     16.290   44.253
7552.0 5312.0  0.0   5296.1 789824.0 648105.7  571776.0   563405.1  61568.0 58090.4    759   27.963  26     16.290   44.253
6464.0 10176.0 6452.6  0.0   880512.0 401761.5  571776.0   565630.1  61568.0 58090.4    760   28.016  26     16.290   44.306
 S0C    S1C    S0U    S1U      EC       EU        OC         OU       PC     PU    YGC     YGCT    FGC    FGCT     GCT
6464.0 10176.0 6452.6  0.0   880512.0 876197.9  571776.0   565630.1  61568.0 58093.7    760   28.016  26     16.290   44.306
9024.0 4928.0  0.0    0.0   840704.0 321404.4  567360.0   469081.9  61440.0 58096.0    761   28.034  27     17.329   45.363

Voici quelques explication sur la signification des entêtes de colonne concernant les zones :

- La première lettre indique la zone : S0 et S1 = survivor 1 et 2, E = Eden, O = Old et P = Permanent

- La dernière lettre indique la mémoire réellement occupée ou la taille réservée : C = Capacity et U = Used

Concernant le GC : YGC = Young GC, YGCT = Young GC Time, FGC = Full GC, FGCT = Full GC Time et GCT = GC Time (temps global)

On voit tout d’abord, que S0 et S1 sont remplis l’un ou l’autre mais pas les deux en même temps. En regardant la colonne YGC, on voit qu’a chaque incrémentation, S0 et S1 permuttent. La taille de l’Eden Space varie également à chaque passage du YGC. On voit également qu’à chaque YGC, le OU augmente afin de stocker les objets les plus anciens de l’Eden Space. Enfin on voit qu’à l’avant dernière ligne, le OU se rapporchait du OC ce qui laissait présager de la saturation de la zone Old Space. La dernière ligne indique donc le passage du FGC qui a eu pour effet de nettoyer le Old Space et de lui réassigner une nouvelle taille.

Que se passe-t-il en cas de fuite mémoire (autrement dit d’objets restant alloués par erreur) ? Le OC grossit de plus en plus, une fois arrivé à son max, le OU se rapproche de la limite. Le FGC passe donc fréquemment au point de ralentir la JVM… puis une belle exception OutOfMemory est déclenchée.

Analyse d’une JVM

Jstat vous permet d’observer l’occupation mémoire, et voir que vous avez effectivement un problème… Mais comment savoir d’où ça vient ? Il existe plusieurs outils, je vous citerai les 2 que j’utilise : jmap et mat.

Jmap est un outil du même style que jstat. Il est livré avec le JDK et permet d’analyser une JVM en cours de fonctionnement. Il permet dans un premier temps d’obtenir une liste des objets actuellement en mémoire, triée par occupation mémoire décroissante. Bien entendu les premières places sont occupées par des objets comme String, byte[], etc, mais si vous voyez une de vos classes dans les 20 premières positions… c’est louche. Pour obtenir cette liste, voici la commande :

jmap -histo <pid>

Si cette liste ne suffit pas à trouver le fautif, vous pouvez utiliser l’artillerie lourde : générer un dump binaire et utiliser un outil qui analysera ce dump vous permettant de naviguer dans vos objets en mémoire. Un dump peut être généré de différentes façons (par exemple jmap ou jconsole). Voici la commande jmap qui génère ce dump :

jmap -heap:format=b

Cette commande correspond à un JDK5 et peut être différente avec un JDK d’une autre version. Attention, si la génération de la liste ne prend que quelques secondes, la génération d’un dump est beaucoup plus longue. Inutile de vous dire que pendant ce temps la JVM est bloquée… donc pour une JVM en exploitation, il vaut mieux le savoir

Différents outils d’analyse existent également. J’utilise pour ma part MAT qui est un plugin Eclipse et existe également dans version autonome. Cette dernière est préférable pour des question d’occupation mémoire (il faut beaucoup de mémoire pour analyser le dump). Cet outil permet d’analyser le dump et de vous suggérer des problèmes possibles. Si cela ne suffit pas (ou si vous pensez qu’il se trompe) vous pourrez alors analyser les objets, trouver leur référence, voir leur contenu, etc.

Squid est le proxy le plus connu, mais étant donné les débits possibles aujourd’hui, l’utilisation d’un proxy est de moins en moins nécessaire. Par contre, en plus de la fonction principale de cache, Squid possède des fonctionnalités intéressantes comme l’ajout de filtrages complémentaires.

SquidGuard est un outil permettant de bloquer l’accès à certaines pages Web, en fonction de différents critères. Cet outil est notamment utilisé par l’éducation nationale pour assurer un contrôle d’accès à Internet dans les établissements scolaires.

L’université de Toulouse met à jour régulièrement des listes noires (blacklist) de sites devant être interdits de consultation par les élèves (donc a priori par mes enfants également). Une page est d’ailleurs consacrée à l’utilisation et la mise en place de SquidGuard.

Installation

Squid est en principe livré avec les différentes distribution de Linux. SquidGuard l’est également dans certaines (c’est le cas dans la version OpenSuse que j’utilise).

Configuration

Il faut avant tout indiquer à Squid d’utiliser SquidGuard pour effectuer un filtrage supplémentaire. Cela se fait en ajoutant la ligne suivante au fichier squid.conf :

url_rewrite_program /usr/sbin/squidGuard -c /etc/squidguard.conf

Un redémarrage de Squid devrait faire appraître des process SquidGuard lancés par Squid.

Mise en place de listes noires

Vous pouvez confectionner vous-même vos blacklistes mais le plus simple est bien entendu d’utiliser des listes déjà éprouvées et mises à jour comme celles de l’université de Toulouse. Elles sont accessibles depuis cette page : http://cri.univ-tlse1.fr/blacklists/. Le fichier blacklists.tar.gz contient toutes les listes et pour une première installation il est sans doute intéressant de l’utiliser.

Les listes doivent être mises en place dans le répertoire indiqué par la variable dbhome du fichier de configuration de SquidGuard (/etc/squidguard.conf dans mon cas).

Prise en compte des listes dans SquidGuard

Il faut alors indiquer à SquidGuard d’utiliser ces listes ou au moins quelques unes (la liste adult est de loin la plus fournie et la plus intéressante en terme de contrôle parental).

dest blacklist {

    domainlist blacklists/adult/domains

    urllist    blacklists/adult/urls

}

Compilation des listes

Afin que SquidGuard soit plus performant et plus rapide au démarrage de Squid, il est possible (voire fortement conseillé) de demander à SquidGuard d’utiliser une base de données pour effectuer son filtrage.

La compilation des listes déclarées dans la configuration se fait à l’aide la commande :

squidGuard -C all

Le reste de la configuration de est assez implicite (déclaration des réseaux et utilisateurs devant être filtrés). Les fonctions avancées peuvent être mises en place en suivant la document de SquiGuard : http://www.squidguard.org/Doc/

Pour activer le filtrage, il suffit alors de configurer l’utilisation du proxy sur les postes qu’on désire protéger. Une solution plus radicale est de configurer au niveau des règles  du firewall l’utilisation automatique du proxy.

Spring met à votre disposition 2 dispositifs rendant l’utilisation de JMS très simple :

- JmsTemplate : gère la connexion vers le serveur déclaré et l’envoi des données

- SimpleMessageListenerContainer : assure la réception des messages et l’appel à votre classe en charge de traiter la réception des objets.

1ère étape : déclaration du serveur

Dans un fichier xml de configuration Spring, insérez ces lignes (dans notre exemple, il s’agit de la déclaration des 2 serveurs ActiveMQ locaux) :

    <!-- ActiveMQ Sender -->
    <bean id="connectionFactorySender" class="org.apache.activemq.ActiveMQConnectionFactory">
        <property name="brokerURL" value="tcp://localhost:61616"/>
    </bean>

    <!-- ActiveMQ Receiver -->
    <bean id="connectionFactoryListener" class="org.apache.activemq.ActiveMQConnectionFactory">
        <property name="brokerURL" value="tcp://localhost:61616"/>
    </bean>

ainsi que la déclaration de la queue qui sera utilisée pour nos échanges de messages :

    <bean id="categs_backup_queue" class="org.apache.activemq.command.ActiveMQQueue">
        <constructor-arg value="categs_backup"/>
    </bean>

2ème étape : gestion de l’émission des messages

Dans notre exemple, nous échangerons des POJOs représentants des catégories afin de les sauvegarder sur un autre serveur.

Voici l’implémentation de la classe servant à envoyer ces messages :

public class CategorieBackupSenderImpl implements CategorieBackupSender {
    private JmsTemplate jmsTemplate;
    private Queue queue;

    @Required
    public void setConnectionFactory(ConnectionFactory cf) {
        this.jmsTemplate = new JmsTemplate(cf);
    }

    @Required
    public void setQueue(Queue queue) {
        this.queue = queue;
    }

    /* (non-Javadoc)
     * @see com.bp.jms.CategorieBackupSender#simpleSend()
     */
    public void send(final Categorie categ) {
        this.jmsTemplate.send(this.queue, new MessageCreator() {
            public ObjectMessage createMessage(Session session) throws JMSException {
              return (ObjectMessage) session.createObjectMessage(categ);
            }
        });
    }
}

Les deux setters servent à Spring pour renseigner les propriétés nécessaires au bon fonctionnement de cette classe : le template (JmsTemplate) qui utilise la connexion au serveur JMS (ConnectionFactory) et la queue (Queue).

La méthode Send fait appel au template pour créer le message à partir de notre POJO via la classe MessageCreator.

Il nous reste à déclarer ce composant dans le XML de configuration Spring :

    <bean id="categorieBackupSender" class="com.bp.categories.jms.impl.CategorieBackupSenderImpl">
        <property name="connectionFactory" ref="connectionFactorySender"/>
        <property name="queue" ref="categs_backup_queue"/>
    </bean>

C’est tout pour l’émission des messages ! La bonne nouvelle c’est que la réception n’est guère plus compliquée

3è étape : gestion de la réception des messages

Voici la classe gérant cette réception :

public class CategorieBackupListener implements MessageListener {

    private CategorieService categorieService;

    /**
     * @param categorieService the categorieService to set
     */
    @Required
    public void setCategorieService(CategorieService categorieService) {
        this.categorieService = categorieService;
    }

    public void onMessage(Message message) {
        if (message instanceof ObjectMessage) {
            try {
                Categorie categ = (Categorie) ((ObjectMessage) message).getObject();
                categorieService.backup(categ);
            }
            catch (JMSException ex) {
                throw new RuntimeException(ex);
            }
        }
        else {
            throw new IllegalArgumentException("Message must be of type ObjectMessage");
        }
    }
}

Le source est assez parlant de lui-même. Suite à la réception du message, le service CategorieService est appelé afin d’effectuer le traitement approprié.

De même que pour l’émission, la configuration Spring est importante…

    <bean id="categorieBackupListener" class="com.bp.categories.jms.CategorieBackupListener">
        <property name="categorieService" ref="categorieService" />
    </bean>

    <bean id="listener" class="org.springframework.jms.listener.SimpleMessageListenerContainer">
       <property name="connectionFactory" ref="connectionFactoryListener"/>
       <property name="destination" ref="categs_backup_queue"/>
       <property name="concurrentConsumers" value="3"/>
       <property name="messageListener" ref="categorieBackupListener"/>
    </bean>

Bien entendu dans cet exemple nous échangeons des POJOs reconnus par JMS comme simple Object. Il est possible d’améliorer tout ça, ne serait-ce que pour s’assurer que l’objet reçu est bien l’objet attendu ou aussi pour échanger des objets de différents types en utilisant la même queue.

4ème étape : fonctionnement de notre exemple

Nous devons déclarer nos deux beans :

        categorieService = (CategorieService) Context.getContext().getBean("categorieService");
        categorieBackupSender = (CategorieBackupSender) Context.getContext().getBean("categorieBackupSender");

puis la récupération de nos objets et leur envoi :

        List<Categorie> categs = categorieService.getCategs();
        if (categs != null) {
            for (Categorie categ: categs) {
                categorieBackupSender.send(categ);
            }
        }

La réception se met en route automatique dès l’instanciation du listener.

Si vous voulez contrôler le fonctionnement du listener, alors il faut déclarer un troisième bean :

        listener = ((SimpleMessageListenerContainer) Context.getContext().getBean("listener"));

Voilà, cet exemple ne présente sans doute pas toutes les possibilités que l’on peut faire de JMS avec Spring, mais c’est un bon début

Postfix vous permet de modifier la route empruntée par les mails envoyés à certains domaines. Il sufit pour cela d’insérer dans le fichier transport ce type de ligne :

<domaine> : [<serveur smtp de destination>]

Par exemple, pour un serveur connecté sur une ligne Free :

aol.com         :[smtp.free.fr]
.aol.com        :[smtp.free.fr]

La seconde ligne permet de gérer les cas où un sous-domaine d’aol.com serait utilisé au sein d’une adresse email.

N’oubliez pas de compiler le fichier transport à l’aide de la commande

postmap transport

et de vérifier que ce fichier transport est bien déclaré dans le fichier main.cf :

transport_maps = hash:/etc/postfix/transport

Edit : vous pouvez ajouter également :

aim.com         :[smtp.free.fr]

-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=<port>
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false

Comme vous l’aurez constaté, il n’y a aucune sécurité d’accès et cela n’est conseillé que pour un serveur présent sur un réseau protégé. Dans certain cas, il est nécessaire d’ajouter :

-Djava.rmi.server.hostname=<IP qui doit écouter sur le port JMX>

Suivant la façon de lancer Tomcat, vous pourrez insérer ces propriétés das le script de démarrage ou dans la variable d’environnement JAVA_OPTS qui est lue par les scripts Tomcat. Il ne vous restera plus qu’à vous connecter avec JConsole sur l’ip et le port indiqué et à scruter toutes les informations délivrées.

L’installation se fait relativement simplement. Voici les quelques points nécesaires :

Téléchargement de la dernière version sur http://roundcube.net/downloads

L’installation en elle-même ne pose pas particulièrement de problème car il suffit de déposer le contnu du tar.gz dans un répertoire vu par apache.

Création des cles ssl

C’est peut-être la partie la plus sensible… Vous pouvez vous aider d’un de mes posts précédents pour cela.

Création d’un vhost sur apache

Voici un exemple de vhost simple :

<IfDefine SSL>
<IfDefine !NOSSL>

<VirtualHost nom_du_serveur:443>

        #  General setup for the virtual host
        DocumentRoot "repertoire_contenant_roundcube"
        ServerName nom_du_serveur:443
        ServerAdmin email_admin_du_serveur
        ErrorLog /var/log/apache2/nom_du_serveur_error.log
        TransferLog /var/log/apache2/nom_du_serveur_access.log

        SSLEngine on
        SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL

        SSLCertificateFile /etc/apache2/ssl.crt/nom_du_certificat_du_serveur
        SSLCertificateKeyFile /etc/apache2/ssl.key/nom_de_la_cle_privee_du_serveur

        SetEnvIf User-Agent ".*MSIE.*" \
                 nokeepalive ssl-unclean-shutdown \
                 downgrade-1.0 force-response-1.0

        CustomLog /var/log/apache2/nom_du_serveur_acess.log ssl_combined

        <Directory "repertoire_contenant_roundcube">
                Options Indexes FollowSymLinks
                AllowOverride None
                Order allow,deny
                Allow from all
        </Directory>

</VirtualHost>

</IfDefine>

Bien entendu il faut activer le ssl en le redémarrant avecl’option startssl qui n’a d’autre mission que de démarrer le process en spécifiant -DSSL sur la ligne de commande.

Configuration de RoundCube

Le fichier INSTALL livré avec RoundCube décrit les opération à faire au niveau de la base de données. Il s’agit en fait de créer une base, le programme de configuration se chargeant alors de créer toutes les tables necessaires.

Il suffit ensuite d’appeler avec un browser l’url http://nom_de_votre_serveur/installer/ afin de compléter les quelques renseignements nécessaires comme la façons d’accéder au smtp, au serveur imap et à la base de données.

Une fois la configuration terminée, il est consillé de supprimer le répertoire /installer pour éviter quelques surprises

L’installation ne présente pas de problèmes particuliers et les quelques opérations sont décrites dans la documentation livrée. Elle est accessible en tapant la commande :

perldoc postgrey

Le lien avec postfix se fait en ajoutant au paramètre smtpd_recipient_restrictions une option check_policy_service inet:127.0.0.1:10023 (à condition d’avoir utiliser tous les paramètres par défaut). Voici par exemple le paramètre complet :

smtpd_recipient_restrictions = permit_mynetworks,reject_non_fqdn_recipient,
        permit_sasl_authenticated,
        check_policy_service inet:127.0.0.1:10023,
        reject_unauth_destination

Une fois le process postgrey lancé (postgrey –inet=10023 -d) et postfix rechargé, les premières traces de contrôle doivent apparaître dans le log postfix.