Étiquette : dns

Envoyer des emails avec un relai smtp hébergé chez Orange (FreeBSD & Sendmail)

Il existe beaucoup d’articles sur ce sujet mais aucun avec la configuration que j’ai mise en place. Du coup je ne sais pas si cela va servir à quelqu’un mais dans le doute je me permets d’expliquer ma configuration. Le but de cet article est d’expliquer comment envoyer des emails depuis votre serveur de messagerie personnel.

L’auto-herbergement de ces types de services (serveur web, serveur mail, serveur de fichiers, etc.) augmente régulièrement depuis de nombreuses années et avec l’arrivée des micro-ordinateurs (comme Raspberry), cette tendance ne fait que de s’amplifier. J’ai donc décidé d’héberger mon serveur de messagerie personnel.

Pour héberger un serveur de messagerie pour lequel vous souhaitez envoyer et recevoir des emails depuis le réseau Internet, vous devez au préalable avoir un enregistrement DNS type MX valide. Pour cela, j’utilise le service de « DNS Dynamic » noip. J’associe à mon enregistrement DNS type A, un enregistrement DNS type MX portant le même nom.

$ host server.noipdomain.net
myserver.mydomain.net has address x.x.x.x
myserver.mydomain.net mail is handled by 10 myserver.mydomain.net.

J’ai mis en place l’environnement technique suivant :

Micro-ordinateur Raspberry 3 Model B
Image RaspBSD (r313109M) (FreeBSD 11.0 pour arm64)
Sendmail avec le support de SASL

La difficulté n’est pas tant de recevoir les emails depuis Internet mais bien de les envoyer depuis votre serveur de messagerie vers Internet. En effet pour éviter la diffusion de SPAM les opérateurs télécoms ont bloqués les connexions (depuis les box) vers les serveurs de messageries. Il est donc nécessaire d’utiliser un relai SMTP valide pour envoyer un email.

Mon fournisseur d’accès Internet est Orange, j’utilise donc leur relai de messagerie (smtp.orange.fr). La connexion au relai de messagerie chez Orange nécessite une authentification (d’où le support de SASL pour Sendmail). Pour une question de sécurité, j’ai créé un compte de messagerie spécifique. La procédure de création d’une boîte aux lettres secondaire est décrite ici.

Vérifier le support de SASL dans Sendmail via la commande suivante :

# /usr/local/sbin/sendmail -d0.1 -bv root
Version x.xx.x
 Compiled with: DNSMAP IPV6_FULL LOG MAP_REGEX MATCHGECOS MILTER
MIME7TO8 MIME8TO7 NAMED_BIND NETINET NETINET6 NETUNIX NEWDB NIS
PICKY_HELO_CHECK PIPELINING SASLv2 SCANF STARTTLS TCPWRAPPERS
USERDB XDEBUG

============ SYSTEM IDENTITY (after readcf) ============
      (short domain name) $w = myserver
  (canonical domain name) $j = myserver.mydomain.net
         (subdomain name) $m = mydomain.net
              (node name) $k = myserver
========================================================

root... deliverable: mailer local, user root

Si le support de SASL n’est pas disponible dans Sendmail, je vous invite à suivre la procédure de compilation d’écrite dans le Handbook de FreeBSD.

Il faut créer le fichier d’authentification au serveur relai de messagerie. J’utilise ici le compte de messagerie spécifique que j’ai créé :

# cat authinfo
AuthInfo:smtp.orange.fr "U:root" "I:xxx@orange.fr" "P:pass" "M:LOGIN"
AuthInfo:smtp.orange.fr:587 "U:root" "I:xxx@orange.fr" "P:pass" "M:LOGIN"

Une fois le fichier généré, il faut créer la table correspondante :

# makemap hash authinfo < authinfo

Il faut insérer les macros suivante à votre configuration de sendmail (modifier le ficher <server>.mc) :

dnl SMART HOST CONFIG
define(`SMART_HOST', `smtp.orange.fr')dnl
define(`RELAY_MAILER_ARGS', `TCP $h 587')dnl
define(`confAUTH_MECHANISMS', `GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
FEATURE(`authinfo',`hash /etc/mail/authinfo.db')dnl
TRUST_AUTH_MECH(`GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl

On génère le fichier de configuration via la commande make et on n’oublie pas de recopier le fichier de configuration :

# cd /etc/mail && make
/usr/bin/m4 -D_CF_DIR_=/usr/local/share/sendmail/cf/   /usr/local/share/sendmail/cf/m4/cf.m4 server.mc > unixme.cf
/usr/bin/m4 -D_CF_DIR_=/usr/local/share/sendmail/cf/   /usr/local/share/sendmail/cf/m4/cf.m4 server.submit.mc > server.submit.cf

# cp server.cf sendmail.cf

Un arrêt / relance de sendmail est nécessaire pour prendre en compte les modifications :

# service sendmail stop
Stopping sendmail.
Waiting for PIDS: 37413.
Stopping sendmail_msp_queue.
Waiting for PIDS: 36932.

# service sendmail start
Starting sendmail.
Starting sendmail_msp_queue.

Maintenant il suffit de tester notre configuration :

$ mail -v -s Test <messagerie@test.fr>
test send
.
EOT

messagerie@test.fr... Connecting to [127.0.0.1] via relay...
220 myserver.mydomain.net ESMTP Sendmail x.xx.x/x.xx.x; Fri, 14 Apr 2017 16:16:59 +0200 (CEST)
>>> EHLO myserver.mydomain.net
250-myserver.mydomain.net Hello localhost [127.0.0.1], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-AUTH DIGEST-MD5 CRAM-MD5 LOGIN PLAIN
250-STARTTLS
250-DELIVERBY
250 HELP
>>> STARTTLS
220 2.0.0 Ready to start TLS
>>> EHLO myserver.mydomain.net
250-myserver.mydomain.net Hello localhost [127.0.0.1], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-AUTH DIGEST-MD5 CRAM-MD5 LOGIN PLAIN
250-DELIVERBY
250 HELP
>>> MAIL From:<moi@myserver.mydomain.net> SIZE=53 AUTH=moi@myserver.mydomain.net
250 2.1.0 <moi@myserver.mydomain.net>... Sender ok
>>> RCPT To:<messagerie@test.fr>
>>> DATA
250 2.1.5 <messagerie@test.fr>... Recipient ok
354 Enter mail, end with "." on a line by itself
>>> .
250 2.0.0 v3EEGxQi037463 Message accepted for delivery
messagerie@test.fr... Sent (v3EEGxQi037463 Message accepted for delivery)
Closing connection to [127.0.0.1]
>>> QUIT
221 2.0.0 myserver.mydomain.net closing connection

Les logs de Sendmail indique les échanges suivants :

Apr 14 16:16:59 myserver sendmail[37462]: v3EEGx4r037462: from=moi, size=53, class=0, nrcpts=1, msgid=<201704141416.v3EEGx4r037462@myserver.mydomain.net>, relay=moi@localhost
Apr 14 16:16:59 myserver sm-mta[37463]: STARTTLS=server, relay=localhost [127.0.0.1], version=TLSv1.2, verify=NO, cipher=ECDHE-RSA-AES256-GCM-SHA384, bits=256/256
Apr 14 16:16:59 myserver sendmail[37462]: STARTTLS=client, relay=[127.0.0.1], version=TLSv1.2, verify=FAIL, cipher=ECDHE-RSA-AES256-GCM-SHA384, bits=256/256
Apr 14 16:16:59 myserver sm-mta[37463]: v3EEGxQi037463: from=<moi@myserver.mydomain.net>, size=383, class=0, nrcpts=1, msgid=<201704141416.v3EEGx4r037462@myserver.mydomain.net>, proto=ESMTPS, daemon=IPv4, relay=localhost [127.0.0.1]
Apr 14 16:16:59 myserver sendmail[37462]: v3EEGx4r037462: to=messagerie@test.fr, ctladdr=moi (1000/0), delay=00:00:00, xdelay=00:00:00, mailer=relay, pri=30053, relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent (v3EEGxQi037463 Message accepted for delivery)
Apr 14 16:17:00 myserver sm-mta[37465]: v3EEGxQi037463: to=<messagerie@test.fr>, ctladdr=<moi@myserver.mydomain.net> (1000/0), delay=00:00:01, xdelay=00:00:01, mailer=relay, pri=30383, relay=smtp.orange.fr. [x.x.x.x], dsn=2.0.0, stat=Sent (8EGz1v00h4tU8mL03EGzx4 mail accepted for delivery)

Le relai de messagerie d’Orange a bien pris en compte l’envoi de l’email. Reste à vérifier depuis le client de messagerie distant la bonne réception de cet email. L’entête du message permet de suivre son cheminement :

...
Received: from smtp.smtpout.orange.fr (smtp08.smtpout.orange.fr [x.x.x.x])
    by in12.mail.test.fr (Postfix) with ESMTPS id 4C012FC3
    for <messagerie@test.fr>; Fri, 14 Apr 2017 16:17:00 +0200 (CEST)
Received: from myserver.mydomain.net ([x.x.x.x])
    by mwinf5d68 with ME
    id 8EGz1v00h4tU8mL03EGzx4; Fri, 14 Apr 2017 16:17:00 +0200
...

Si jamais vous avez des questions ou besoin de plus de détails sur la configuration mise en place , nécessitez pas à me les poser via un commentaire.

Utilisez des adresses SCAN sans DNS

L’installation par défaut d’une couche Grid Infrastructure nécessite un certain nombre d’adresses IP (avec résolution) pour notamment l’utilisation de la fonctionnalité SCAN. Par exemple si vous utilisez deux instances systèmes pour construire une couche Grid Infrastructure, vous devez réserver au moins neuf adresses IP différentes avec des noms associés.

Explication :

1 @ IP + 1 nom pour l’instance système 1 dans le réseau dit publique
1 @IP + 1 nom pour l’instance système 2 dans le réseau dit publique
1 @IP + 1 nom pour l’instance système 1 dans le réseau dit privé
1 @IP + 1 nom pour l’instance système 2 dans le réseau dit privé
1 @IP + 1 nom pour l’instance système 1 dans le réseau dit publique (VIP)
1 @IP + 1 nom pour l’instance système 2 dans le réseau dit publique (VIP)
3 @IP + 1 nom dans le réseau dit publique (SCAN)

Ces couples « adresses IP + noms » sont « normalement » enregistrés dans un service DNS (ce n’est pas obligatoire pour le réseau dit privé). Vous pouvez néanmoins vous passez d’un service DNS en spécifiant l’ensemble de ces adresses IP + ces noms dans le fichier hosts de chaque instance système où vous souhaitez déployer la couche Grid Infrastructure.

Ci-dessous un exemple d’entrées d’un fichier hosts pour l’installation d’une couche Grid Infrastructure sur deux instances systèmes.

#-- Nodes --#

# Public network
192.168.10.5 rac1
192.168.10.6 rac2
# Private network
192.168.100.5 rac1-priv
192.168.100.6 rac2-priv

#-- Cluster --#

# VIP address
192.168.10.100 rac1-vip
192.168.10.101 rac2-vip
# SCAN address
192.168.10.102 oraclu01-scan
192.168.10.103 oraclu01-scan
192.168.10.104 oraclu01-scan

Essayez maintenant d’installer une couche Grid Infrastructure en utilisant uniquement une résolution local sans que les enregistrements des couples adresses IP + noms soient indiqués dans le service DNS. Le défi est lancé…

Vous obtiendrez surement ces erreurs dans vos logs d’installation de la couche Grid Infrastructure. Cela fera suite à l’exécution du CVU (Cluster Verify Utility).

INFO: -----------------------------------------------
INFO: Verification Result for Node:rac2
WARNING: Result values are not available for this verification task
INFO: Error Message:PRVG-1101 : SCAN name "oraclu01-scan" failed to resolve
INFO: Cause: An attempt to resolve specified SCAN name to a list of IP addresses failed because SCAN could not be resolved in DNS or GNS using ''nslookup''.
INFO: Action: Check whether the specified SCAN name is correct. If SCAN name should be resolved in DNS, check the configuration of SCAN name in DNS. If it should be resolved in GNS make sure that GNS resource is online.
INFO: Error Message:PRVF-4657 : Name resolution setup check for "oraclu01-scan" (IP address: 192.168.10.102) failed
INFO: Cause: Inconsistent IP address definitions found for the SCAN name identified using DNS and configured name resolution mechanism(s).
INFO: Action: Look up the SCAN name with nslookup, and make sure the returned IP addresses are consistent with those defined in NIS and /etc/hosts as configured in /etc/nsswitch.conf by reconfiguring the latter. Check the Name Service Cache Daemon (/usr/sbin/nscd) by clearing its cache and restarting it.

INFO: Error Message:PRVF-4657 : Name resolution setup check for "oraclu01-scan" (IP address: 192.168.10.103) failed
INFO: Cause: Inconsistent IP address definitions found for the SCAN name identified using DNS and configured name resolution mechanism(s).
INFO: Action: Look up the SCAN name with nslookup, and make sure the returned IP addresses are consistent with those defined in NIS and /etc/hosts as configured in /etc/nsswitch.conf by reconfiguring the latter. Check the Name Service Cache Daemon (/usr/sbin/nscd) by clearing its cache and restarting it.
INFO: Cause: Inconsistent IP address definitions found for the SCAN name identified using DNS and configured name resolution mechanism(s).
INFO: Action: Look up the SCAN name with nslookup, and make sure the returned IP addresses are consistent with those defined in NIS and /etc/hosts as configured in /etc/nsswitch.conf by reconfiguring the latter. Check the Name Service Cache Daemon (/usr/sbin/nscd) by clearing its cache and restarting it.

INFO: Error Message:PRVF-4657 : Name resolution setup check for "oraclu01-scan" (IP address: 192.168.10.104) failed
INFO: Cause: Inconsistent IP address definitions found for the SCAN name identified using DNS and configured name resolution mechanism(s).
INFO: Action: Look up the SCAN name with nslookup, and make sure the returned IP addresses are consistent with those defined in NIS and /etc/hosts as configured in /etc/nsswitch.conf by reconfiguring the latter. Check the Name Service Cache Daemon (/usr/sbin/nscd) by clearing its cache and restarting it.

Etrangement l’utilitaire CVU d’Oracle tente d’obtenir une résolution DNS pour l’enregistrement SCAN (qui lui indiqué en paramètre de l’installation via la GUI ou via un fichier réponse). Que vous ayez configuré ou non un service DNS sur les instances systèmes, les erreurs ci-dessous se produiront.

L’utilitaire CVU exécute toujours une résolution DNS du nom SCAN. Si le nom SCAN est oraclu01-scan, l’utilitaire Oracle exécute la sous-commande suivante.

# /usr/sbin/nslookup oraclu01-scan

La réponse à cet incident est d’utiliser un service DNS avec des enregistrements correctes !? Et vous auriez raison de le faire. Cependant il existe une autre solution basée sur la mise en place d’un script (en lieu et place du binaire nslookup).

Ci-dessous la méthodologie à suivre pour remplacer le binaire nslookup par un script (à faire bien entendu sur toutes les instances systèmes où la couche Grid Infrastructure sera déployée).

# mv /usr/sbin/nslookup /usr/sbin/nslookup.orig
# touch /usr/sbin/nlookup
# chmod +x /usr/sbin/nslookup

Il faut éditer ce nouveau fichier nslookup et y ajouter le contenu ci-desssous en l’adaptant notamment avec vos informations réseaux.

#!/bin/bash

LISTE=$*
HOSTNAME="${@: -1}"

if [[ $HOSTNAME = "oraclu01-scan" ]];
then
    echo "Server:          192.168.112.30"
    echo "Address:         192.168.112.30#53\n"
                        
    echo "Name:     oraclu01-scan"
    echo "Address:  192.168.112.102"
    echo "Name:     oraclu01-scan"
    echo "Address:  192.168.112.103"
    echo "Name:     oraclu01-scan"
    echo "Address:  192.168.112.104"
else
    /usr/sbin/nslookup.orig $LISTE
fi

Cette solution vous permettra ainsi d’installer une couche Grid Infrastructure sans utiliser des enregistrements DNS spécifiques pour l’ensemble des couples adresses IP + noms. Cette solution est viable dans des environnements type « tests d’infrastructure », elle ne l’est certainement pas dans des environnements avec des utilisateurs.

J’ai perdu mon DNS

Je ne vais pas vous parler d’un phénomène paranormal bien qu’au premier abord cela m’a paru assez étrange.

Lors de l’initialisation d’un cluster Oracle Rac (12c) dans des Kernel Zone Solaris (11.3), la configuration DNS mise en place (via le service smf dns/client) disparaissait étrangement. J’ai accusé à tort le processus d’initialisation d’Oracle Rac en cherchant en vain ce qui pouvait provoquer ce changement de configuration DNS. J’imagine les sourires de mes collègues d’Oracle quand j’ai posé la question sur les listes de support interne !? Je suis passé pour un fou… Quoique.

Il y a bien évidement une réponse technique à cette erreur. Solaris 11 utilise des profils de configuration réseau (Network Configuration Profil – NCP) selon deux modes : manuel ou automatique.

Le choix du mode s’effectue lors de l’installation du système Solaris. Si NCP utilise le mode automatique, le protocole DHCP est activé sur l’une des interfaces réseau du système. Les éléments de configuration suivants adresse IP, route par défaut et serveurs DNS sont alors obtenus par le service DHCP. La perte des paramètres DNS provenait donc de cette mauvaise configuration du profil NCP.

Pour vérifier votre configuration NCP, il suffit de saisir la commande suivante :

# netadm list

Comme vous pouvez le voir ci-dessous la configuration automatique est activée :

# netadm list -x Automatic
TYPE        PROFILE        STATE          AUXILIARY STATE
ncp         Automatic      online         active
ncu:phys    net0           online         interface/link is up
ncu:ip      net0           online         interface/link is up
loc         Automatic      online         active

Par défaut le mode automatique permet la configuration du service DNS :

# netcfg list loc automatic
loc:Automatic
        activation-mode                 system
        enabled                         false
        nameservices                    dns
        nameservices-config-file        "/etc/nsswitch.dns"
        dns-nameservice-configsrc       dhcp

Pourquoi ce mode automatique ? Le mode automatique a été principalement mis en œuvre pour simplifier la configuration réseau des ordinateurs portables. Ce mode ne convient absolument pas à des serveurs comme vous avez pu le lire. La modification du mode automatique en mode manuel a fixé définitivement mon erreur.

Je vous invite à lire (ou plutôt relire) l’excellent article de Andrew Walton concernant ce sujet.