Installation et configuration du service SNMP par GPO

Dans le cas du Monitoring (et notamment avec WhatsUp Gold sous Windows), il sera utilise d’installer le service SNMP sur les machines devant être monitorées.

Cette procédure, certes facile, deviendra vite agaçantes si on doit la réaliser pour une grande quantité de machine.

La réalisation d’une GPO permettra de rendre cette tâches plus « amusante ».

Nous allons réaliser cette GPO sur une serveur Windows 2008 R2 par l’intermédiaire d’un script en Powershell qui s’occupera de l’installation et la configuration du service SNMP sur les machines membres du domaine.

Le Script

# Adresse du serveur WhatsUp + nom de communauté
 $manager = "IP.DE.LA.MACHINE"
 $commstring = "public"

# Import ServerManager Module
Import-Module ServerManager
$adresseSource = "\\domain.local\NETLOGON"    

# Dossier sources des fichiers de config.  
cls  
$check = Get-WindowsFeature | Where-Object {$_.Name -eq "SNMP-Services"}    
If ($check.Installed -ne "True") 
{  
Add-WindowsFeature SNMP-Services | Out-Null cls  $check = Get-WindowsFeature | Where-Object {$_.Name -eq "SNMP-Services"
}  
If ($check.Installed -eq "True")
{  
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\SNMP\Parameters\ PermittedManagers" /v 2 /t REG_SZ /d $manager /f  Foreach ( $string in $commstring){ 
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\SNMP\Parameters\ValidCommunities" /v $string /t REG_DWORD /d 4 /f  
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\SNMP\Parameters\TrapConfiguration\$string" /v 1 /t REG_SZ /d $manager /f } 
# Démarrage du service SNMP si non fait Start-Service "SNMP" >> .\logScript.txt }

 Création et configuration de la GPO

Nom choisi pour la GPO : SNMP

On applique la GPO sur les machines (et pas les utilisateurs) à leur démarrage :

Nous choisissons « Startup » et nous nous rendons dans l’onglet « PowerShell Scripts » de la fenêtre qui vient de s’ouvrir.

Il faut ajouter le script au bon emplacement. Pour y parvenir :

Ce qui donne au final :

Nous nous rendons ensuite dans Administrative Templates afin d’activer l’exécution des scripts.

Chemin complet: Computer Configuration > Policies > Administrative Templates > Windows Components > Windows PowerShell > Turn On Script Execution

Ensuite nous nous rendons à l’emplacement suivant : Computer Configuration > Policies > Administrative Templates > Windows Components > System > Scripts :

Il faut activer “Run Windows PowerShell scripts at computer startup”, “Run Logon scripts synchronously” et “Run startup scripts visible”.

Ensuite, nous devons ajouter un template (le fichier .ADM peut être téléchargé sur le site de Microsoft : http://www.microsoft.com/en-us/download/details.aspx?id=25119) afin de ne pas à avoir à exécuter la commande Set-ExecutionPolicy unrestricted sur chaque machine. Si nous ne le faisons pas, il sera impossible de lancer un script sans passer par l’interpréteur PowerShell.

On va chercher le fichier ou il se trouve et on l’ajoute :

Il ne faut pas oublier de lier la GPO SNMP :

Nous allons maintenant ajouter un filtre WMI si l’on ne désire pas que la GPO s’applique sur le serveur ou elle se trouve :

Nous devons lui donner un nom, éventuellement une description et écrire la requête à effectuer :

Résumé de la GPO :

Un petit gpupdate /force dans la console et le tour est joué.

Résultat depuis une machine membre du domaine

Pour voir si tout s’est bien passé au démarrage de la machine, il suffit d’aller voir dans Services :

Et si nous allons voir les propriétés du Service SNMP, nous devons normalement retrouvé les informations du script :

 Et voilà qui est fait :)

Le serveur mail de A à Z

Ce serveur mail a été réalisé sur une Ubuntu 10.04.3 LTS mais le développement reste le même sur une Debian. Nous supposerons que le DNS est bien configuré (présence d’un enregistrement MX valable) et prêt à remplir correctement son rôle.

Pour ceux qui débuteraient dans le domaine, quelques explications s’imposent:

Un utilisateur est abonné chez domaine1.com et a comme adresse e-mail expediteur@domaine1.com. Un autre est abonné chez domaine2.org avec comme adresse e-mail destinataire@domaine2.orgexpediteur souhaite envoyer un e-mail à destinataire.

Voici ce qu’il va se passer :

    1. expediteur rédige le message avec son client de messagerie (appelé aussi Mail User Agent). Lorsque le message a été rédigé, expediteur l’envoie par le biais de son MUA;
    2. Le serveur smtp.domaine1.com (correspondant au MTA, Mail Transfert Agent) reçoit alors le message, il constate que le destinataire n’est pas dans son domaine. Il va donc chercher l’enregistrement MX dans le DNS de domain2.org.
      Il envoie le message à smtp.domaine2.org ;
    3. Le serveur smtp.domaine2.org reçoit à son tour le message et constate que le destinataire est bien dans son domaine. Il range le message dans la boîte aux lettres de destinataire par l’intermédiaire du MDA (Mail Delivery Agent).
    4. Lorsque destinataire décidera de regarder s’il a des nouveaux messages, il enverra une requête à son serveur imap.domain2.org au moyen de son client de messagerie;
    5. Le client de messagerie va chercher sur le serveur IMAP et consulte la boîte aux lettres de destinataire et constate qu’il y a un message dedans;
      Le message est visible dans le MUA.

Voici les différents outils qui seront utilisés:

  • Postfix (le serveur SMTP)
  • Courier-IMAP (le serveur IMAP)
  • Procmail (le MDA)
  • Amavis avec SpamAssassin et ClamAV (Antispam et Antivirus)

Postfix:

Installons tout d’abord le paquet nécessaire à l’utilisation de Postfix:

# apt-get install postfix

Normalement, quelques questions nous sont demandées:

General Type of configuration? --> Internet
Site Where should mail for root go--> On laisse blanc
Mail name? --> mail.server.be
Other destinations to accept mail for? (blank for none) --> mail.server.be, localhost
Force synchronous updates on mail queue ? --> No
Local networks ? --> 127.0.0.0/8
Use procmail for local delivery--> Yes
Mailbox size limit --> 0
Local address extension character? --> +
Internet protocols to use --> all

Il se peut parfois, lors de l’installation qu’aucune information ne soit demandée, il est possible de répondre à ces questions ultérieurement, en utilisant la commande suivante :

# dpkg-reconfigure postfix

Ensuite, nous devons modifié l’un des 2 fichiers essentiels au bon fonctionnement de Postfix, à savoir main.cf (le 2ème fichier est master.cf, ce fichier contient des informations diverses sur le comportement de Postfix et sa façon de faire résider les différents daemons ):

# nano /etc/postfix/main.cf
myhostname = mail.server.be
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname

mydestination = mail.server.be, localhost.server.be ,localhost
relayhost =
mynetworks = 127.0.0.0/8, 172.23.0.0/16, 192.168.0.0/16
#mailbox_command = /usr/bin/procmail
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
home_mailbox = Maildir/ # Si pas précisé, les mails iront dans /var/mail

Ce fichier contient la configuration principale de Postfix.

Quelques explications sur les différentes lignes de ce fichier: 

myhostname = mail.server.be

Cette option doit contenir le nom de domaine (FQDN) du serveur.

alias_database = hash :/etc/aliases

Fichier de type hash contenant une table d’alias mail. Celle-ci est éditable dans /etc/aliases, puis régénérée en hash grâce à la commande newaliases qui produit le fichier /etc/aliases.db
Cette étape est indispensable pour prendre en compte les changements.

myorigin = /etc/mailname

Cette option va indiquer le fichier qui contient une seule ligne décrivant le nom de domaine utilisé.
Dans ce cas-ci, /etc/mailname contient mail.server.be.
Il est essentiel de vérifier l’exactitude du contenu de ce fichier. Il faut que le nom de domaine soit bon sinon on aura quelques soucis.

mydestination = mail.server.be, localhost.server.be, localhost

Liste des domaines pour lesquels le serveur doit accepter le courrier.

mynetworks = 127.0.0.0/8, 172.23.0.0/16, 192.168.0.0/16

Contient la liste des réseaux locaux autorisés.

mailbox_command = /usr/bin/procmail

Commande pour utiliser Procmail comme MDA. Pas utilisé pour l’instant, on le commente.

mailbox_size_limit = 0

Limite de taille en octets pour les boîtes aux lettres, un zéro signifie qu’il n’y a pas de réstriction.

recipient_delimiter = +

Séparateur entre le nom d’utilisateur et les extensions d’adresse (par défaut le signe +).

inet_interfaces = all

Interfaces réseaux sur lesquelles le serveur va écouter.
Ici, on écoute sur toutes les interfaces.

Nous allons maintenant créer une adresse e-mail. Rien de plus simple, il suffit de créer un nouvel utilisateur:

# adduser test

On répond aux différents champs et on fixe un mot de passe pour l’utilisateur.

Pour tester si tout fonctionne correctement avant de continuer, essayons d’envoyer un mail à test:

# echo "Ceci est le contenu de mon mail" | mailx -s "ceci est le sujet" test@mail.server.be

Le mail sera automatiquement déposé dans le répertoire Maildir situé dans le répertoire personnel de test. S’il n’existe pas, le dossier Maildir sera automatiquement créé.

On peut s’assurer que le mail est arrivé en se rendant dans le répertoire personnel ou en utilisant les logs :

# cat /var/log/mail.log

Pour augmenter la sécurité du serveur de manière significative, il faut à présent parler des notions de TLS et de SASL (SSL).

Cette partie est assez délicate à réaliser, une minuscule erreur et on peut passer toute sa journée à essayer de trouver où est le problème.

Installons les paquets nécessaires:

# apt-get install libsasl2 sasl2-bin libsasl2-modules

Générons ensuite les certificats SSL auto signés pour Postfix :

# mkdir /etc/postfix/ssl
# cd /etc/postfix/ssl/
# openssl genrsa –des3 –rand /etc/hosts –out smtpd.key 1024

Nous devons choisir un passphrase (permet de sécuriser la clé privée).

Ensuite, il faut changer les permissions d’accès à l’aide d’un chmod :

# chmod 600 smtpd.key
# openssl req -new -key smtpd.key -out smtpd.csr

Quelques questions nous sont posées et comme d’habitude, on fait bien attention au Common Name. Il doit impérativement correspondre à mail.server.be.

Utilisons, à présent, les commandes suivantes (un passphrase est à nouveau demandé):

# openssl x509 -req -days 3650 -in smtpd.csr -signkey smtpd.key -out
smtpd.crt
# openssl rsa -in smtpd.key -out smtpd.key.unencrypted
# mv -f smtpd.key.unencrypted smtpd.key
# openssl req -new -x509 -extensions v3_ca -keyout cakey.pem -out cacert.pem -days 3650

Maintenant que les certificats ont été générés, modifions la configuration de Postfix en ajoutant quelques lignes dans le fichier main.cf pour activer le TLS (ou s’assurer que les lignes suivantes y sont déjà):

smtpd_use_tls= yes
smtpd_tls_auth_only = no
smtpd_tls_key_file = /etc/postfix/ssl/smtpd.key
smtpd_tls_cert_file = /etc/postfix/ssl/smtpd.crt
smtpd_tls_CAfile = /etc/postfix/cacert.pem
smtpd_tls_loglevel = 3
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom

Ajoutons quelques lignes (toujours dans main.cf) concernant la partie SASL (permettant une authentification):

smtpd_sasl_local_domain = $myhostname
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous 
broken_sasl_auth_clients = yes

Le daemon d’authentification utilisé sera saslauthd:

# mkdir -p /var/spool/postfix/var/run/saslauthd
# rm –rf /var/run/saslauthd

Cette commande est très importante pour éviter d’avoir des erreurs lors du test avec testsaslauthd.

# ln -s /var/spool/postfix/var/run/saslauthd /var/run/saslauthd
# chgrp sasl /var/spool/postfix/var/run/saslauthd
# adduser postfix sasl
# nano /etc/default/saslauthd

Dans ce fichier précédemment créé, on ajoute/vérifie les lignes suivantes :

START=yes
MECHANISMS="pam"
OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd"

Ensuite, allons dans le fichier smtpd.conf:

# nano /etc/postfix/sasl/smtpd.conf
pwcheck_method: saslauthd
mech_list: login plain

Dans ce fichier, j’ai dû préciser quelle méthode et quel format allaient être utilisés.
Concernant le deuxième fichier de Postfix, le master.cf, il suffit juste de décommenter les lignes suivantes (et de commenter celle concernant le port 25 afin d’autoriser uniquement l’envoi d’emails de manière sécurisée):

smtps inet n - - - - smtpd
 -o smtpd_tls_wrappermode=yes
 -o smtpd_sasl_auth_enable=yes
 -o smtpd_client_restrictions=permit_sasl_authenticated,
reject

Il ne reste plus qu’à démarrer salsauthd et redémarrer Postfix pour prendre en compte la nouvelle configuration :

# /etc/init.d/saslauthd start
# /etc/init.d/postfix restart

On peut ensuite tester le bon fonctionnement grâce à la commande :

# testsaslauthd -u test -p Password

Courier-IMAP:

On procède à l’installation des paquets nécessaires:

# apt-get install courier-imap courier-authdaemon

Nous devons modifier une ligne dans le fichier de configuration de Courier-IMAP. Ce fichier se situe dans /etc/courier et se nomme imapd.
Il s’agit de celle concernant le MAILDIRPATH, c’est-à-dire le chemin pour accéder aux boîtes aux lettres.

On retourne alors dans le dossier de notre utilisateur et on fait :

# maildirmake Maildir

Cette commande va créer une boîte aux lettres complète chez un utilisateur. On aura un utilisateur par boîte mail.
A partir d’ici, tout est normalement fonctionnel et on peut tester avec notre logiciel de messagerie (comme Thunderbird par exemple).

Pour ce qui est de la sécurité, installons les paquets suivants :

# apt-get install courier-imap-ssl

Il faut alors modifier le fichier imapd-ssl par défaut qui se trouve dans /etc/courier/ :

TLS_CERTFILE=/etc/postfix/ssl/mail.combined.npw.pem
IMAP_TLS_REQUIRED=1
MAILDIRPATH=Maildir

Utilisons la commande suivante pour supprimer le passphrase sur le certificat cakey.pem (si ce n’est pas fait, une erreur sera visible dans les logs):

# openssl rsa –in cakey.pem -out cakey.nopw.pem

Ici, il y a une subtilité à prendre en compte. Contrairement à Postfix, le daemon IMAP exige que le certificat et la clé privée soient combinés en un même fichier.

On concatène:

# cat cacert.pem cakey.nopw.pem >> mail.combined.npw.pem
# openssl dhparam 1024 >> mail.combined.npw.pem

Il faut ensuite exécuter 2 commandes afin d’éviter une erreur « error:0906D06C:PEM routines:PEM_read_bio:no start line » dans les logs :

# chmod 400 mail.combined.npw.pem (ou 777 si cela est vraiment nécessaire)
# chattr +i mail.combined.npw.pem

Un petit redémarrage s’impose :

# /etc/init.d/courier-authdaemon restart
# /etc/init.d/courier-imap restart
# /etc/init.d/courier-imap-ssl restart

Procmail, Amavis et SpamAssassin :

Nous installons, comme toujours, les paquets nécessaires:

# apt-get install procmail amavisd-new clamav clamav-daemon spamassassin
spamc

Pour pouvoir utiliser Procmail, il faut créer un fichier dans le dossier de notre utilisateur test :

# touch .procmailrc

C’est donc dans ce fichier que seront placées les règles de filtrages. Il faut être très vigilent pour le faire fonctionner et faire très attention au droit mis sur ce fichier.
Il faut s’assurer que l’utilisateur en question soit propriétaire de ce fichier, si ce n’est pas le cas :

# chown test:test .procmailrc

Pour ce qui est des droits d’accès sur le fichier :

# chmod 600 .procmailrc

Ce qui va fixer les permissions à rw——-.
C’est-à-dire que le propriétaire aura accès en lecture et écriture (rw-) et les membres du groupe et les autres n’auront pas d’autorisation ().

En ce qui concerne ClamAV et Amavis , après l’installation chacun crée de son côté un utilisateur et un groupe. Afin que ClamAV puisse accéder aux pièces jointes décompressées par Amavis, il faut le rajouter au groupe amavis :

# addgroup clamav amavis

Pour autoriser le filtrage de ClamAV et SpamAssassin, éditons le fichier 15-content_filter_mode qui se trouve dans /etc/amavis/conf.d/:

@bypass_virus_checks_maps = ( \%bypass_virus_checks, \@bypass_virus_checks_acl, \$bypass_virus_checks_re);
@bypass_spam_checks_maps = ( \%bypass_spam_checks, \@bypass_spam_checks_acl, \$bypass_spam_checks_re);

Pour que des e-mails lui soient confiés, ajoutons ceci dans le fichier main.cf :

content_filter = scan:127.0.0.1:10024

On se rend alors dans l’autre fichier master.cf pour rajouter :

smtp-amavis unix - - y - 2 smtp
 -o smtp_data_done_timeout=1200
 -o disable_dns_lookups=yes

scan unix - - n - 16 smtp
-o smtp_send_xforward_command=yes

127.0.0.1:10025 inet n - y - - smtpd
-o content_filter=
-o local_recipient_maps=
-o relay_recipient_maps=
-o smtpd_restriction_classes=
-o smtpd_client_restrictions=
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o mynetworks=127.0.0.0/8
-o strict_rfc821_envelopes=yes

A présent, il faut s’assurer que SpamAssassin se lance au démarrage du système, ouvrons le fichier /etc/default/spamassassin et modifions la valeur de ENABLED :

ENABLED=1

Ensuite, on modifie la ligne concernant le nombre maximum de processus à exécuter :

OPTIONS= “--max-children 5 –helper-home-dir”

–max-children correspond au nombre d’enfants à lancer par spamd (le daemon de SpamAssassin). Aucun autre enfant ne sera lancé tant qu’un des 5 actuels ne sera pas mort. Cette option sert à éviter que trop de processus soient lancés en même temps afin de préserver la mémoire.

La configuration de SpamAssasin se fait dans le fichier local.cf présent dans /etc/spamassassin.
Dans ce fichier, il est possible de déterminer le message devant apparaitre en avant de l’en-tête :

rewrite_header Subject *****SPAM*****

Ainsi que le score au-delà duquel le message sera considéré comme spam :

required_score 10.0

Redémarrage pour prendre en compte la configuration:

# /etc/init.d/amavis restart
# /etc/init.d/clamav-daemon restart
# /etc/init.d/spamassassin restart
# /etc/init.d/postfix restart

Maintenant que les étapes nécessaires au bon fonctionnement de ces outils sont accomplies, passons au comportement souhaité de ceux-ci.

C’est dans le fichier de Procmail que tout va se passer.
Pour les spams, le comportement sera différent suivant le score, si c’est un virus, on aura aussi un comportement différent.

Il est nécessaire de créer le fichier .procmailrc dans le Home Directory de chaque utilisateur.

Au début du fichier, il faut impérativement ceci :

SHELL=/bin/sh
#PATH=${HOME}/bin:/usr/bin:/bin
DEFAULT=$HOME/Maildir/
MAILDIR=$HOME/Maildir
#LOGFILE=$HOME/.procmail.log
VERBOSE=yes
DROPPRIVS=yes
#LOGABSTRACT=all
#LOCKFILE=${HOME}/.procmail/lock

A la suite de ceci, on peut commencer à écrire nos règles :

# Permet de suivre l’email au travers du daemon spamc
# (l’interface de SpamAssassin)
:0fw
| /usr/bin/spamc
# Si l’email obtient un score de 20  supprimé
:0
* ^X-Spam-Level: *\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
/dev/null
# Si l’email obtient un score de 10
#  placé dans spam
:0
* ^X-Spam-Level: *\*\*\*\*\*\*\*\*\*
$MAILDIR/.spam/
# Si l’email est détecté comme virus
#  placé dans virus
:0:
* ^X-Amavis-Alert: INFECTED
$MAILDIR/.virus/
# Si l’email est à la fois un virus et un spam
:0:
* ^X-Amavis-Alert: INFECTED
* ^X-Spam-Status: Yes
/dev/null
# on le supprime

Haute disponibilité avec Pacemaker et Corosync

Tout d’abord un bref descriptif de la haute disponibilité:

On appelle « haute disponibilité » (en anglais « high availability ») toutes les dispositions visant à garantir la disponibilité d’un service, c’est-à-dire assurer le bon fonctionnement d’un service 24H/24.

Le terme « disponibilité » désigne la probabilité qu’un service soit en bon état de fonctionnement à un instant donné.

Pacemaker and Corosync

Nous allons tout d’abord installer les 2 outils qui seront nécessaires:  Corosync et Pacemaker.

Corosync va permettre de mettre les serveurs utilisés en cluster et Pacemaker va s’occuper de la gestion des ressources. 

# apt-get install corosync
# apt-get install pacemaker

Passons maintenant à la configuration de Corosync. Le fichier de configuration devra être le même sur chaque noeud

 # nano /etc/corosync/corosync.conf

Il va falloir faire quelques modifications afin d’éviter l’apparition d’erreurs:

token: 5000
token_retransmits_before_loss_const: 20
join: 1000
consensus: 7500
max_messages: 20
secauth: on # We use a key to allow a node to connect to the cluster

Nous allons maintenant définir une interface réseau qui autorisera la communication entre les différents noeuds:

interface {
 ringnumber: 0
 bindnetaddr: 10.10.10.0 // Adresse réseau à adapter selon le cas
 mcastaddr: 226.94.1.1
 mcastport: 5405
 }

Intégrons maintenant le service Pacemaker au cluster de Corosync. 
Assurons nous que le fichier de configuration de Corosync contienne bien les lignes suivantes:

service {
 # Load the Pacemaker Cluster Resource Manager
 ver: 0
 name: pacemaker
}

On va maintenant s’occuper de l’authentification. Une clé a été générée durant l’installation des packages, il est possible d’en recréer une de cette manière:

# corosync-keygen

Ensuite on va envoyer la clé à/aux autre(s) noeud(s) (dans notre cas nous n’aurons que 2 serveurs, donc 2 noeuds):

# scp /etc/corosync/authkey root@My_other_node:/etc/corosync

La configuration du cluster étant terminée, il faut maintenant activer Corosync:

# nano /etc/default/corosync

On redémarre alors le service:

# /etc/init.d/corosync start

Passons maintenant à la configuration de Pacemaker:

Note : Pour se connecter à la console de Pacemaker, on se contente d’utiliser la commande suivante:  crm_mon -1

Sur n’importe lequel des noeuds, on va se connecter au CLI (Common-Line Interface) pour configurer le cluster de Pacemaker (afin de définir le comportement désiré):

# crm

Il est possible de connaître notre configuration déjà existante en utilisant la commande suivante :

# configure
# show

On exécute ensuite la commande suivante (toujours en mode configure):

# property stonith-enabled="false" no-quorum-policy="ignore"

Stonith est un composant de Pacemaker qui permet au système de redémarrer le serveur qui a échoué. Dans notre cas, ce composant est désactivé. Nous allons également ignoré la perte du quorum  (le nombre minimum de noeuds en ligne afin de permettre la validation  d’une décision). Avec un cluster de 2 noeuds, il n’y a pas de quorum quand un noeud est perdu. L’opération par défaut quand il n’y a pas de quorum est de couper toutes les ressources.

On peut s’assurer de la bonne configuration en utilisant la commande show.
On doit alors forcer la prise en compte des changements sur tous les noeuds en utilisant la commande commit.

Service Actif/Passif

Le service sera lancé et supervisé par Pacemaker, pas besoin de le lancer au démarrage du système. Pour désactiver ce lancement sur une Debian (Squeeze):

# insserv –r –v service

Le service qui sera supervisé devra être installé et configuré de la même manière sur chacun des noeuds.

Le VIP est l’adresse virtuelle utilisée pour accéder aux service avec haute disponibilité. Cette adresse sera ajoutée comme une seconde adresse sur l’interface de notre choix.

Les commandes suivantes doivent être réalisées sur les 2 noeuds (l’adresse IP sera modifiée selon le cas):

# crm configure
# primitive VIP1 ocf:heartbeat:IPaddr2 \
params ip="192.168.1.100" broadcast="192.168.1.255" nic="eth0" cidr_netmask="24" iflabel="VIP1" \
op monitor interval="30s" timeout="20s"
# commit

Une nouvelle interface, appelée eth1: VIP1, vient d’être ajoutée.

Nous allons à présent ajouter le service. Nous nous occuperons ici d’Apache, mais le processus est le même pour d’autres services.
Toujours en mode configure (et sans oublier le commit à la fin), nous ajoutons:

# primitive APACHE ocf:heartbeat:apache \
params configfile="/etc/apache2/apache2.conf" \
op monitor interval="30s" timeout="20s" \
op start interval="0" timeout="40s" \
op stop interval="0" timeout="60s"

Malheureusement, en utilisant la commande show, on peut voir que VIP1 est lancé sur un serveur et qu’Apache l’est sur l’autre. Il faut qu’ils soient lancés sur le même.

Certains changements doivent être faits.
Il faut que le service tourne sur un des noeuds et qu’en cas de perturbation du service, celui-ci passera sur l’autre noeud (après 3 tentatives).

# crm configure
# group APACHE-HA VIP1 APACHE meta migration-threshold="3"
# commit
APACHE and VIP1 are grouped in the APACHE-HA group.

Nous désactivons également l’auto-failback. Le noeud restera en mode passif même lorsque le problème aura été résolu.

# crm configure
# property default-resource-stickiness= « 10 »
# commit

Les tests

On coupe le serveur qui fait tourner le service, les ressources sont transmises à l’autre serveur et reste actives sur celui-ci même si le serveur (anciennement actif) et redémarré.

On pourrait aussi couper Apache. Après la 3ème tentative pour le relancer, le sercice est lancé sur l’autre noeud.
Il faudra alors remettre à zéro le compteur sur le noeud qui a rencontré des erreurs:

# crm resource cleanup APACHE-HA

Bonding sous Linux

Le bonding sous Linux est l’équivalent de l’etherchannel de chez Cisco ou encore le portchannel de chez H3C. Mais si cela ne vous parle pas encore, il s’agit en fait de faire du « teaming » (ou fusion) entre plusieurs interfaces réseau en une seule.

Quelle est l’avantage d’une telle manœuvre ? En réalité, on peut faire du teaming de plusieurs sortes qui présentent toutes de vrais avantages.

On peut par exemple configurer notre bonding pour avoir un lien actif et un lien de backup (mode Active-Backup) ce qui permet d’avoir une disponibilité garantie en cas de chute d’un des liens.

On peut également le configurer en mode broadcast ce qui nous permettrait d’envoyer les paquets sur toutes les interfaces et ainsi est insensible aux erreurs sur un des liens.

Un autre mode intéressant est le 802.3ad (plus connu sous Link Aggregation) qui permet de réunir plusieurs interfaces physique en une interface logique et, ainsi, nous permettre de doubler, tripler, quadrupler la bande passante d’un lien.

Mais comment configurer cela sous Linux. Rien de bien compliquer. Nous allons voir ici une configuration sous CentOS (manipulation compatible RedHat et dérivés).

Tout d’abord, modifions le fichier /etc/modprobe.conf pour y rajouter les lignes suivantes :

alias bond0 bonding
options bond0 miimon=80 mode=5

En créant l’alias bond0, nous définissons une nouvelle interface nommée bond0 en lui associant plusieurs options. L’une des options importante est le mode. Ce mode nous permet de créer un bonding en choisissant le mode qu’on désire.

Voici la liste des modes disponibles :

mode=0 (Balance Round Robin)
mode=1 (Active backup)
mode=2 (Balance XOR)
mode=3 (Broadcast)
mode=4 (802.3ad)
mode=5 (Balance TLB)
mode=6 (Balance ALB)

Une fois le fichier modprobe.conf modifié, il faut créer la nouvelle interface bond0. Nous allons donc créer le fichier /etc/sysconfig/network-scripts/ifcfg-bond0

# nano /etc/sysconfig/network-scripts/ifcfg-bond0
DEVICE=bond0
IPADDR=X.X.X.X
NETMASK=X.X.X.X
GATEWAY=X.X.X.X
ONBOOT=yes
BOOTPROTO=none
USERCTL=no

IPADDR est l’ip de notre interface logique , NETMASK le masque de sous-réseau et GATEWAY la passerelle par défaut.

Ensuite, il faut configurer les interfaces qui feront parties de ce bonding :

# nano /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
ONBOOT=yes
BOOTPROTO=none
USERCTL=no
MASTER=bond0
SLAVE=yes

On fait la même manipulation pour eth1, eth2, … , ethX. MASTER étant l’interface logique à laquelle on veut associer l’interface.

Une fois tout cela fait, on peut relancer le service :

# /etc/init.d/network restart

Un petit ifconfig nous permettra de voir si notre interface bond0 est bien créée.

 

A très bientôt pour un autre tuto :-)

Google Apps Migration for Microsoft® Exchange

 

Si vous utiliser votre propre serveur mail (avec Postfix et Courier-IMAP par exemple) et que vous désirez migrer vers une solution telle que Gmail. Cet utilitaire est fait pour vous.

Explication: 

Google Apps Migration for Microsoft® Exchange pouvant être abrégé en « GAMME « est un utilitaire permattant de transférer en autres les messages (il est également possible de transférer l’agenda et les données de contacts) d’un serveur Exchange ou IMAP vers Google Apps.

Les serveurs IMAPs pris en compte sont:

  • Courier
  • Dovecot
  • Cyrus
  • Zimbra
  • Gmail
  • Novell(TM) Groupwise®
  • SunMail

Pour pouvoir utiliser ce software, il sera nécessaire d’avoir un compte Google Apps for Business ou Google Apps for Education. Le compte gratuit ne permet pas d’utiliser un tel outil.

Le téléchargement de Google Apps Migration for Microsoft® Exchange se fait ici :

https://tools.google.com/dlpage/exchangemigration

Prérequis avant utilisation de GAMME

Avant de pouvoir utiliser GAMME pour procéder à la migration, il est important de passer d’abord par quelques points importants.

La plupart des manipulations à effectuer se feront sur ce site :

https://www.google.com/a/cpanel/NomDeDomaine/Dashboard

Partons du principe que la validation du domaine (qui est exigée après création du compte) est accomplie et que Gmail est opérationnel.

Pour pouvoir utiliser GAMME, il faut d’abord suivre les instructions suivantes

  • Se rendre dans Outils avancés puis Authentification
  • On clique sur Gérer l’accès de tiers aux clients OAuth
    1. Dans « Nom du client », on rentre notre nom de domaine
    2. Dans «Une ou plusieurs étendues d’API », on copie les 3 liens suivants séparés par une virgule : https://apps-apis.google.com/a/feeds/migration/, https://www.google.com/calendar/feeds/https://www.google.com/m8/feeds/
  • On retourne ensuite en arrière et on se rend maintenant dans : Gérer la clé de domaine OAuth
    1. On active la clé client
    2. On peut éventuellement autoriser l’accès à toutes les API mais si on choisit de cocher ceci, il est inutile de réaliser le point 2.
  • On copie le code secret client OAuth car il sera utile par après
  • Ensuite, on se rend maintenant dans l’option « Paramètres » puis « Adresse E-mail »
  • Dans « Transfert des e-mails de l’utilisateur » on vérifie que « Permettre aux utilisateurs de transférer des e-mails à l’aide de l’API Email Migration (les administrateurs ont toujours accès à cette API) » est bien coché, sinon on le coche nous-même.

Après avoir créé les utilisateurs sur Google Apps, pour faire le lien avec l’utilisateur du notre propre serveur mail, il faut créer un fichier .csv. Ce fichier devra respecter la syntaxe suivante :

userid#password, user_google

Dans notre cas, userid correspondra au nom de notre utilisateur sur Postfix/Courier, le mot de passe sera celui de cet utilisateur et user_google sera le nom de l’utilisateur sur Gmail.

Maintenant que tout ceci est fait, on peut passer à l’étape suivante.

Utilisation de GAMME

Après l’avoir installé via le lien précédemment cité, on lance le logiciel.

Une fenêtre s’ouvre nous laissant le choix du type de serveur entre Exchange ou IMAP. Dans notre cas, c’est IMAP qui a été utilisé, on coche donc IMAP.

On nous demande :

  • Le serveur IMAP utilisé
  • Hostname/IP
  • La sécurité utilisée
  • Le port
  • Et le préfixe utilisé pour nos BAL

Voici à quoi cela ressemble une fois complété :

On clique sur Next et on arrive à la 2ème étape.

Ici, on va préciser le nom de domaine Google Apps, le consumer key et le consumer secret ainsi que le fichier csv précédemment créé.

L’étape 3 concerne des options additionnelles :

  • Migrer uniquement les mails après une certaine date, ou avant une certaine date
  • Limite la migration simultanée à x utilisateurs
  • Ne pas migrer certains dossiers (dans notre cas il est inutile de migrer les dossiers spams et virus)

Un récapitulatif nous est montré, ou il est également possible de modifier certaines valeurs :

 Run diagnostic permet de vérifier la bonne configuration avant de continuer vers la migration.

On peut également sauvegarder les paramètres rentrés pour ne pas avoir à le refaire la prochaine fois.
Si tout est correct, on doit avoir ceci :

On passe à l’étape suivante en cliquant sur Start. Cette étape va vérifier les différents dossiers, calculés le nombre de messages qu’ils contiennent et permettre ainsi la migration.
Si tout se passe, bien la migration commence directement (car on a coché « Migrate » lors du récapitulatif).

Si tout s’est bien déroulé :

Bien entendu, plus il y aura d’utilisateurs et de messages, plus la durée du processus sera de plus en plus importante. Par contre, l’efficacité de ce procédé atteint pratiquement les 100 %, donc l’attente en vaut la peine.

Le résultat dans Gmail

Les emails qui ont été migré gardent leur état (lu, non lu) ainsi que la date à laquelle ils avaient été réceptionnés sur l’ancien serveur.

Les dossiers qui contenaient des mails, et qui n’existaient pas dans Gmail, ont également été créés.

Erreurs commises durant les tests

Tout d’abord, il faut être très vigilent quand on réalise le .csv car une minuscule erreur et on peut rester bloquer très longtemps sans savoir pourquoi.

On aura alors une erreur de ce type :

 On peut également avoir une erreur à l’étape suivante sans avoir de Failed pour autant.

Cette erreur peut apparaitre lorsqu’un dossier ou un fichier n’a rien à faire dans le Maildir.
Par exemple, j’avais une erreur à cause de mon .procmail.log car le logiciel pensait que c’était un dossier alors que non.
Donc si on a ce genre d’erreurs, on supprime ou on déplace le fichier/dossier (si il est vide cela peut aussi poser problème) et on redémarre la migration qui ne devrait plus retourner d’erreur.

Une erreur de ce type ”Failure: Migrating 2 / 2 messages from folder virus for store=test2 Error:00000000” indique quels messages n’ont pas été migrés vers Google Apps. Les messages qui ne sont pas migrés concernent ceux qui dépassent la taille de 25 MB, ceux avec pièce-jointes de plus de 20 MB, ceux qui contiennent des fichiers exécutables (pas permis dans Gmail), les messages duplicés, des messages dans des dossiers avec un nom protégé dans Gmail (System Labels, etc).
Mais si la migration se termine avec succès, il n’est pas nécessaire de s’inquiéter à propos de cette erreur.

Si on une erreur de ce type  « Failed with 0x80070005, last successful line = xxx » est causé le plus couramment par un problème d’autorisations, il faut s’assurer que les comptes utilisateurs disposent des droits nécessaires pour permettre à l’utilitaire de consulter les BALs des utilisateurs. En d’autres termes, il faut s’assurer que les messages présents dans les BALs sont bien possédés par l’utilisateur en question.

Pour accéder aux logs du logiciel :

C:\Documents and Settings\UserName\Local Settings\Application Data\Google\Google Apps Migration\Tracing\ExchangeMigration