# uname -a - Mot-clé - serveur

La délégation NS d'un sous-domaine, cet illustre inconnu

Mathieu — Tue, 05 Mar 2019 09:15:00 +0100

Un billet un peu technique aujourd'hui. Si vous travaillez dans le Web, vous n'êtes pas sans savoir que c'est le mécanisme des DNS qui fait en sorte que vos noms de domaine soient résolus en adresses vers votre hébergement.

Vous savez aussi peut-être ce qu'est une zone DNS. Une zone DNS est un bête fichier présent sur le serveur DNS, et qui contient l'ensemble des enregistrements du domaine¹.

Vous savez aussi certainement ce qu'est un sous-domaine, par exemple pour le domaine example.com, des sous-domaines seraient :

www.example.com
test.example.com
sousdomaine.example.com

Parfois, pour séparer les services, on souhaite aller encore plus loin et dédier un sous-domaine entier à une tâche, par exemple on souhaite faire en sorte que compta.example.com soit totalement indépendant, c'est à dire :

Qu'on puisse recevoir sur l'email facturation@compta.example.com ,
Qu'on puisse avoir des mini-sites dédiés sous ce sous-domaine, comme urssaf.compta.example.com ou creances.compta.example.com
Que le sous-domaine puisse servir tout autre usage tel que permis par les DNS (enregistrements SRV, etc)

Bien sûr, ces usages sont possibles à partir de la zone DNS du domaine parent, mais à mesure que le sous-domaine grandit en indépendance (et donc en nombre d'enregistrements), il peut être nécessaire de poser les bases d'une délégation plus avancée, pour éviter de maintenir une zone avec tous les enregistrements. On peut aussi vouloir déléguer à un prestataire la gestion de ce sous-domaine.

Pour ce qui est des mini-sites, il est relativement simple de déclarer un wildcard pour rediriger tous les enregistrements d'un sous-domaine vers un même serveur. Mais lorsqu'on veut plus de souplesse, ou que l'on veut aussi déléguer tous les enregistrements de ce sous-domaine, un wildcard est trop "brutal" et pas toujours supporté par toutes les spécifications, il faut alors déléguer la zone via une délégation NS.

En deux images

Requête DNS classique : le serveur répond au client avec un enregistrement A

Requête DNS déléguée : le serveur répond d'aller interroger un autre serveur,
le client transmet la requête à l'autre serveur et obtient l'enregistrement A.

En exemple

Prenons un exemple de la vie réelle. Sortez votre commande dig, et examinez le domaine pingveno.net :

dig +trace pingveno.net @8.8.8.8

pingveno.net.        172800    IN    NS    ns-197-a.gandi.net.
pingveno.net.        172800    IN    NS    ns-150-b.gandi.net.
pingveno.net.        172800    IN    NS    ns-153-c.gandi.net.
;; Received 733 bytes from 192.52.178.30#53(k.gtld-servers.net) in 46 ms

pingveno.net.        3600    IN    A    xx.xx.xx.xx
;; Received 57 bytes from 217.70.187.154#53(ns-153-c.gandi.net) in 45 ms

Dans l'exemple ci-dessus, j'ai retiré les appels du root server car ils ne sont pas pertinents pour notre exemple. On constate que la requête est transmise aux serveurs de Gandi, qui répondent directement avec l'enregistrement A du domaine.

Nouvel exemple, avec le sous-domaine uname.pingveno.net :

dig +trace pingveno.net @8.8.8.8

pingveno.net.        172800    IN    NS    ns-197-a.gandi.net.
pingveno.net.        172800    IN    NS    ns-150-b.gandi.net.
pingveno.net.        172800    IN    NS    ns-153-c.gandi.net.
;; Received 737 bytes from 2001:501:b1f9::30#53(m.gtld-servers.net) in 114 ms

pingveno.net.        3600    IN    A    xx.xx.xx.xx
www.pingveno.net.    10800    IN    CNAME    pingveno.net.
;; Received 75 bytes from 217.70.187.154#53(ns-153-c.gandi.net) in 44 ms

Cette fois le serveur répond avec un CNAME vers pingveno.net, c'est la méthode "pas chère" de déléguer le sous-domaine à un autre enregistrement. Ce n'est pas un wildcard, puisque l'enregistrement est seul, mais le résultat aurait été le même avec un wildcard.

Enfin, essayons avec ishimaru.pingveno.net :

dig +trace ishimaru.pingveno.net @8.8.8.8

pingveno.net.        172800    IN    NS    ns-197-a.gandi.net.
pingveno.net.        172800    IN    NS    ns-150-b.gandi.net.
pingveno.net.        172800    IN    NS    ns-153-c.gandi.net.
;; Received 742 bytes from 192.41.162.30#53(l.gtld-servers.net) in 45 ms

ishimaru.pingveno.net.    10800    IN    NS    a.ns.wellhosted.ch.
ishimaru.pingveno.net.    10800    IN    NS    b.ns.wellhosted.ch.
;; Received 98 bytes from 213.167.230.151#53(ns-150-b.gandi.net) in 44 ms

ishimaru.pingveno.net.    60    IN    A    xx.xx.xx.xx
ishimaru.pingveno.net.    3600    IN    NS    b.ns.wellhosted.ch.
ishimaru.pingveno.net.    3600    IN    NS    a.ns.wellhosted.ch.
;; Received 130 bytes from 2a03:2040:d:121::1#53(a.ns.wellhosted.ch) in 49 ms

Cette fois, le serveur a répondu en deux temps : il a indiqué un enregistrement NS sur le sous-domaine, puis le client (ici la commande dig) a continué la requête vers les serveurs indiqués dans l'enregistrement NS pour retourner finalement l'adresse IP.

C'est une délégation NS. Cela signifie que tout le sous-domaine (la zone complète) de ishimaru.pingveno.net n'est pas gérée par gandi.net, mais par a.ns.wellhosted.ch . De cette manière, le sous-domaine est totalement indépendant, et peut être utilisé pour tous les usages d'un domaine de niveau supérieur.

Conclusion

C'est tout, ce court article sert juste à démystifier l'enregistrement NS, qui est très peu souvent utilisé, d'une part par la méconnaissance de la plupart des "webdesigners" se contentant de pointer des sous-domaines en A ou en AAAA, et ensuite parce qu'il faut pouvoir déléguer à un serveur DNS, tous les prestataires ne sont pas équipés pour accueillir un domaine de cette façon.

Notes

¹ : L'ensemble, ou presque, le serveur DNS ne portant que la zone sur laquelle il a autorité, tout le travail du client DNS consiste justement à interroger les serveurs DNS en cascade, pour arriver à l'enregistrement qui fait autorité. Pas d'exposé là dessus aujourd'hui, mais vous pouvez lire la doc.

SSL vs TLS vs STARTTLS

Mathieu — Mon, 13 Jun 2016 17:03:00 +0200

Cet article est une traduction libre de https://www.fastmail.com/help/technical/ssltlsstarttls.html

J'ai réalisé cette traduction pour fournir à mes clients une explication simple mais complète sur le pourquoi du comment de SSL/TLS/STARTTLS lors de la configuration de leur client mail.

Attention, l'article original date de 2012.

Définitions

Protocole : un protocole de communication est un format de données, un "langage" permettant à deux machine de communiquer entre elles. Les deux machines doivent être en capacité de parler le même protocole pour pouvoir échanger des données. SSL est un protocole de communication sécurisé ("chiffrés"), popularisé par le célèbre "cadenas" visible sur les pages web.
Port : un port est un numéro de service sur lequel les logiciels vous pouvoir communiquer entre eux. La plupart des numéros de port sont associés à des protocoles précis.

Introduction

Il y a souvent de la confusion autour des différents termes SSL, TLS and STARTTLS.

SSL et TLS fournissent tous deux un moyen de chiffrer le canal de communication entre deux ordinateurs (par exemple votre ordinateur et votre serveur mail). TLS est le successeur de SSL et les termes SSL et TLS sont interchangeables, à moins que vous ne fassiez référence à une version particulière du protocole.

STARTTLS est un moyen de prendre une connexion non chiffrée existante, et la "mettre à jour" vers une connexion sécurisée en utilisant SSL/TLS. Notez que même s'il contient TLS dans son nom, STARTTLS ne signifie pas que vous devez obligatoirement utiliser TLS, vous pouvez utiliser SSL.

Numéros de version SSL/TLS

La numérotation des versions du protocole est inconsistante entre SSL et TLS. Lorsque TLS a remplacé SSL comme protocole préférentiel pour les communications chiffrées, il a commencé avec une nouvelle numérotation de versions, et a également commencé à utiliser des sous-versions. L'ordre des versions des protocoles du plus ancien au plus récent est donc : SSL v2, SSL v3, TLS v1.0, TLS v1.1, TLS v1.2.

Lorsque vous vous connectez sur un port chiffré avec SSL/TLS, ou que vous utilisez STARTTLS pour convertir la connexion en connexion chiffrée, les deux systèmes vont négocier quel protocole et quelle version utiliser, en se basant ce qui a été configuré et sur ce que chaque système supporte.

Le support pour SSL/TLS est "virtuellement" universel de nos jours, mais le support des versions est variable. Pratiquement tous les systèmes supportent SSL v3 (à part quelques rares appareils Palm Treo comme nous avons pu le constater). La plupart des systèmes supportent TLS v1.0. À la date de Mai 2012, le support pour TLS v1.1 et TLS v1.2 est beaucoup plus restreint.

Dénomination incorrecte TLS vs STARTTLS

Pour compliquer les choses, certains logiciels de mail utilisent incorrectement le terme TLS à la place de STARTTLS. Les plus vieilles versions de Thunderbird en particulier utilisent "TLS" pour dire « utiliser STARTTLS pour chiffrer la connexion dès que possible et abandonner si STARTTLS n'est pas supporté » et « TLS, si disponible » signifie « utiliser STARTTLS pour chiffrer la connexion dès que possible si le serveur déclare le supporter, sinon utiliser simplement une connexion non chiffrée ».

Numéros de ports SSL/TLS vs plaintext/STARTTLS

Le problème du dessus est particulièrement problématique lorsque vous devez configurer des ports différents pour chaque protocole.

Pour ajouter de la sécurité à certains protocoles (e.g. IMAP, POP, etc.), il a été décidé d'ajouter nativement une couche de chiffrement SSL/TLS dans le protocole. Cependant, pour identifier que le logiciel doit parler la version nativement chiffrée du protocole au lieu de la version non chiffrée, un port différent a été déclaré pour chaque protocole. Vous avez donc :

IMAP utilise le port 143, mais IMAP avec SSL/TLS utilise le port 993.
POP utilise le port 110, mais POP avec SSL/TLS utilise le port 995.
SMTP utilise le port 25, mais SMTP avec SSL/TLS utilise le port 465.

Au bout d'un moment, il a été décidé qu'utiliser deux ports pour chaque protocole était du gaspillage, et qu'à la place il devrait y avoir un seul port sur lequel commencer la communication de manière non chiffrée, puis proposer au système distant de mettre à jour vers la version chiffrée. C'est ce pour quoi STARTTLS a été créé.

Il y a eu quelques problèmes avec cette proposition. Il y avait déjà des logiciels qui utilisaient les numéros de port alternatifs avec une connexion SSL/TLS native. Les logiciels clients peuvent avoir une durée de vie très longue, donc vous ne pouvez pas juste désactiver les ports chiffrés avant que tous les logiciels ne soient remplacés ou mis à jour.

Des mécanismes ont été mis en place sur chaque protocole pour dire aux systèmes que le protocole non chiffré supportait STARTTLS, et qu'ils ne doivent pas essayer de se connecter avant de démarrer la négociation STARTTLS. Cela créa deux situations malheureuses :

Certains logiciels ignoraient simplement l'instruction « login désactivé jusqu'à ce que la connexion soit convertie en SSL avec STARTTLS » et essayaient de se connecter tout de même, envoyant leur login et mot de passe à travers la connexion non chiffrée. Même si le serveur à ce moment là rejette le login, les informations sont déjà passées en clair sur Internet.
D'autres logiciels voyaient l'annonce « login désactivé jusqu'à conversion en SSL », mais ne mettaient pas à jour leur connexion automatiquement, et renvoyaient des erreurs « mot de passe incorrect » à l'utilisateur, ce qui provoqua de la confusion sur ce qui était incorrect dans la configuration.

Ces deux problèmes causèrent finalement d'importantes incompatibilités entre les logiciels existants, et la plupart des administrateurs systèmes continuèrent d'utiliser les connexions exclusivement non sécurisés sur le port d'origine, et les connexions SSL natives sur un port alternatif.

C'est donc devenu de fait le standard que tout le monde utilise. IMAP SSL/TLS chiffré sur le port993 ou POP SSL/TLS chiffré sur le port 995. Beaucoup de sites (dont FastMail) désactive à présent le port IMAP non sécurisé (port 143) et le port POP non sécurisé (port 110) pour que les utilisateurs utilisent obligatoirement une connexion chiffrée SSL/TLS. En désactivant les ports 143 et 110, cela supprime également complètement STARTTLS, même en tant qu'option pour les connexions IMAP/POP.

SMTP STARTTLS comme une exception

La seule vraie exception à ce qui précède est SMTP. Cependant, c'est pour une raison différente. La plupart des logiciels email utilisent utilisaient le port 25 pour soumettre des messages à envoyer au serveur mail. Cependant, SMTP a été créé à l'origine comme un protocole d'échange de messages, et non de soumission. Un autre port (587) a donc été déclaré pour la soumission de messages. Bien que le port 587 ne nécessite pas explicitement STARTTLS, l'utilisation du port 587 est devenu populaire au même moment où l'utilisation de SSL/TLS était devenue un enjeu important de sécurité et de confidentialité.

Le résultat c'est que dans la plupart des cas, les systèmes qui proposent la soumission par le port 587 nécessitent que les logiciels utilisent STARTTLS pour chiffre la connexion, et nécessitent aussi un login et un mot de passe pour s'identifier. Il y a plusieurs avantages à cette approche. En écartant les utilisateurs du port 25, les FAI ont été en mesure de bloquer le port 25 pour prévenir les envois automatiques de SPAM causés par l'infection des postes de leurs utilisateurs.

Actuellement, les choses semblent encore aléatoires, divisées entre les gens qui utilisent SMTP SSL/TLS chiffré sur le port 465, et les gens qui utilisent SMTP avec STARTTLS sur le port 587.

NDLR : SMTPS sur le port 465 est aujourd'hui définitivement obsolète.

Diminuer le taux de rejet des mails sortants pour un fournisseur de boîtes mail

Mathieu — Tue, 09 Feb 2016 21:06:00 +0100

En théorie, tout le monde peut s’improviser fournisseur d’emails, il suffit d’une machine avec les ports ouverts sur Internet et de quelques connaissances pour configurer le serveur mail (Postfix, Exim…)

En pratique, les fournisseurs de mails subissent la « concurrence déloyale » de leur camarades, car envoyer un mail c’est bien, faire en sorte qu’il soit reçu c’est mieux. Les « concurrents » ce sont les fournisseurs de service comme Hotmail, Gmail, Yahoo, et bien d’autres. Afin de lutter contre le SPAM, ces sociétés sont de plus en plus strictes sur la source des mails qui sont reçus par leurs services.

Une des conséquences c’est que les petits opérateurs, comme une start-up qui fournit de l’hébergement, un FAI associatif, ou même un particulier qui veut se réapproprier Internet, se font bloquer assez rapidement avec peu de solutions de recours, le support faisant souvent la sourde oreille.

Dans cet article, je vais donc explorer quelques pistes pour vous permettre d’abord d’éviter de vous retrouver bloqués, et ensuite contourner le blocage le cas échéant.

Ce billet est le produit de mes expériences avec l'hébergeur wellhosted.

Réputation (et monitoring)

Déjà, si vous avez une adresse IP dynamique, oubliez l’envoi de mails. Il est très difficile avec une IP dynamique d’assurer à la fois une réception correcte (même avec un MX pointant sur un DynDNS), et un envoi qui réussisse à tous les coups. D’ailleurs, la plupart des opérateurs proposant des IPs dynamiques bloquent le port 25, rendant l’envoi des mails « entre serveurs » impossible.

Ensuite, la seconde bonne raison pour avoir une IP fixe, c’est que les contrôlent antispam reposent en grande partie sur la réputation des IPs qui leur envoient des mails. Ce mécanisme s’appelle le RBL pour Realtime Block List. Les serveurs s’abonnent à des listes d'adresses IP connues pour émettre du SPAM, et refusent de recevoir les mails depuis ces IPs. Pas de chance si vous avez hérité d’une IP « qui pue », il vous faudra patiemment demander votre retrait de la liste de blocage au cas par cas.

Il existe des outils pour tester votre IP sur un grand nombre de RBL : mxtoolbox.com/blacklists.aspx

Vous pouvez également mettre en place une surveillance automatique de votre réputation sur plusieurs blocklists, soit avec un simple plugin Nagios, soit avec un outil comme RBLMon.

A noter que certaines listes ne permettent pas de faire « retirer » votre IP de la liste. Pas d’inquiétude pour ces listes, personne ne les utilise. Il existe par contre des fournisseurs de service qui ne publient pas leurs listes, et qui ont un processus contraignant pour se faire débloquer (Microsoft par exemple).

Une fois que votre IP est fixe et qu'elle est propre, l’étape suivante c’est conserver la réputation de votre IP et être irréprochable sur les mails que vous envoyez, mail nous verrons cela dans la suite.

IPv6

Même si ce n’est pas indispensable, IPv6 est le futur d'Internet, et de nombreux serveurs mails parlent IPv6. En utilisant IPv6, vous aurez aussi l’avantage que beaucoup de RBL ne sont pas prêtes pour IPv6, et donc votre IP ne sera certainement pas bloquée sur ces listes.

Revers de la médaille : oubliez l’utilisation d’une IPv6 exclusive, certains fournisseurs de mail utilisent encore exclusivement IPv4, il vous faudra donc une configuration réseau supportant les deux adressages pour être certain de pouvoir livrer vos mails.

Reverse, PTR, et Hostname

Le « Reverse », parfois nommé « PTR », est une résolution DNS inverse. De la même façon qu'une résolution DNS permet de passer d'un nom de domaine à une adresse IP, le DNS inverse permet de passer d'une adresse IP à un nom de domaine. Ce mécanisme existe aussi bien pour IPv4 que pour IPv6.

Si votre fournisseur de service (la personne chez qui vous louez les IPs ou les serveurs) ne vous permet pas de changer le Reverse, changez de prestataire immédiatement ! L'envoi d'un mail à partir d'une adresse IP sans Reverse est souvent rédhibitoire pour le serveur mail de destination (pas de reverse, pas de livraison).

De plus, votre Reverse doit être consistant :

L'adresse IP doit résoudre vers un domaine, et ce même domaine doit résoudre vers l'adresse IP.
Le serveur mail doit également fournir son nom de domaine principal dans le processus de négociation, et ce nom doit résoudre correctement vers son IP. Réglez donc les /etc/hostname ; /etc/mailname et myhostname (pour Postfix) correctement.

Une inconsistance à un quelconque niveau est pire qu'une absence de reverse : le serveur de destination considérera qu'il y a peut-être usurpation de l'IP.

Encore une fois, n'oubliez pas de régler aussi le reverse IPv6 si vous utilisez IPv6 sur votre serveur.

Postmaster, Hostmaster, et RFC

Certains serveurs mails sont un peu soupe au lait. Par exemple, il peut arriver que votre réputation descende en flèche juste parce que le propriétaire du serveur n’a pas de moyen automatisé de vous contacter.

J’explique : dans les RFC (Request For Comment, la base des normes et protocoles sur Internet), il est prévu qu’un serveur mail émettant du courrier possède des adresses particulières, à savoir postmaster@ledomaine.com et hostmaster@ledomaine.com permettant de recevoir les mails envoyés automatiquement par ses pairs.

postmaster recevra principalement les plaintes pour SPAM, notification de traffic inhabituel sur les mails, et autres requêtes relatives aux mails
hostmaster recevra les mails relatifs à la gestion du nom de domaine lui-même (demandes de transfert, contact légal du propriétaire - même si on préfère souvent écrire aux contacts du whois), ou parfois pour la réservation d’un certificat SSL (vérification de la propriété du nom de domaine avant délivrance automatique du certificat).

L’absence d’une adresse postmaster@ valide sur votre serveur vous fait donc paraître pour le serveur mail de destination comme un spammeur qui n’a même pas pris la peine d’implémenter correctement le protocole mail.

A noter qu’un alias de postmaster@ vers une adresse de votre choix fonctionne aussi, même si cette adresse est un trou noir. Mais vous ne devriez pas ignorer les notifications automatiques de blocage et de plaintes envoyées à postmaster…

De la même façon, préférez un logiciel de serveur mail respectueux des standards (Postfix, Exim) au tout-dernier-serveur-mail-a-la-mode, dont les réponses ne sont peut-être pas entièrement conformes aux RFC.

Limites

Là on touche au grand dilemme du fournisseur de mails en serveur mutualisé : offrir plus de possibilités aux utilisateurs, ou se protéger contre les usages abusifs ?

Concrètement, imaginons qu’un de vos utilisateurs décide d’envoyer de la publicité aux 500 adresses mail de sa liste de contacts. Les serveurs recevant un tel volume de messages d’un seul coup ne vont peut-être pas apprécier ce trafic non sollicité et encombrant (de la pub ? du SPAM ? Paf, bloqué).

Pire : imaginez qu’un de vos utilisateurs se fasse pirater sa boîte mail, et devienne un émetteur de SPAM ou de virus à partir de votre serveur mail ? Vous pensez que les serveurs de destinations seront compréhensifs s’ils reçoivent des centaines de mails par seconde provenant de votre serveur mail ? Ils ne chercheront pas à comprendre : paf, bloqué.

La solution dans un premier temps c’est de limiter le nombre de mails envoyés par votre serveur, par adresse et par jour. Chaque utilisateur ne devrait par exemple envoyer que 300 mails par jour. Au-delà, le compte sera bloqué en attendant que l’on détermine si c’est une utilisation légitime ou non. La limite est bien entendu à calibrer selon les utilisateurs et les services que vous voulez offrir.

Il existe plusieurs solutions pour implémenter ce comportement, voici la mienne : github.com/mpellegrin/ratelimit-policyd

Diminuer la vitesse d’envoi

Ça peut paraître un comble au moment où l’on veut recevoir les informations le plus vite possible, et pourtant c’est souvent nécessaire pour l’envoi de mails. Afin d’éviter d’envoyer trop vite un grand volume de mail d’un coup, il peut être nécessaire de mettre en place une limite de mails sortants par seconde et par domaine de destination. Ainsi, le serveur mail de destination ne sera pas inondé sous le poids des mails à traiter, et sera plus coopératif pour les recevoir (en résumé : il ne vous bloquera pas pour usage abusif de sa bande passante).

La mitigation du taux d’envoi peut être faite au moyen de simples paramètres pour le serveur mail steam.io/2013/04/01/postfix-rate-limiting/

DKIM et SPF

Avoir un enregistrement SPF valide pour le domaine avec lequel vous envoyez vos mails est pratiquement obligatoire : non seulement cela vous permettra de confirmer que le serveur qui envoie vos mails y est bien autorisé, mais cela vous protégera (un peu) contre les usurpations d'adresses mail. Un exemple de SPF serait :

v=spf1 +a +mx -all

Si vous voulez un effet positif maximal, préférez un réglage strict ("-all") au réglage de debug ("?all"), quitte à élargir votre jeu de règles en insérant toutes vos IPs. Par contre, ne mettez pas un TTL trop haut sur les enregistrements SPF, on ne sait jamais.

Attention également, pour configurer votre domaine, le champ de type "SPF" est obsolète, utilisez un champ de type TXT pour vos enregistrements SPF.

En complément au mécanisme SPF, parce que le SPF n'est pas toujours suffisant pour assurer au serveur de destination que le mail est légitime, vous pouvez mettre en place le DKIM pour tous vos mails sortants. La configuration est plus complexe, mais elle vaut largement le coup pour vous faire sortir de l'ornière d'une réputation trop faible de votre adresse IP dans les premiers mois.

Le principe du DKIM c'est d'ajouter une signature aux mails, cette signature étant calculée à partir d'une clef privée. La clef publique est quant à elle publiée dans un enregistrement TXT dans le nom de domaine, permettant au serveur recevant le mail de vérifier la validité de la signature, et donc la légitimité du message envoyé à partir du nom de domaine.

Smarthosts

Si finalement tout ce dont j'ai parlé plus haut n'a pas fonctionné, et que vous vous êtes fait bloquer sur le réseau d'un des grands fournisseurs de boîtes mail (Google, Microsoft, yahoo...), voici votre dernier recours.

Outre changer d'adresse IP, ce qui pose souvent d'autres problèmes, votre solution c'est d'utiliser un Smarthost. Le Smarthost, c'est tout simplement un serveur mail qui transfère des mails. C'est ce que l'on appelle aussi un relay mail, qui va renvoyer tous vos mails à la place de votre serveur bloqué.

Dans l'idéal vous devriez avoir plusieurs smarthosts, pour pouvoir répartir la charge de traitement, et les échanger lorsque l'adresse IP de l'un d'eux se fait bloquer. Ainsi vous ne touchez pas à vos MX, et vous avez un réseau permettant de faire sortir des mails indépendemment de votre réseau de réception.

Le routage vers le Smarthost se règle très simplement dans Postfix, en utilisant la directive transport_maps de Postfix et en configurant un second serveur mail (le smarthost) en mode Relay.

Attention cependant au moment de créer votre smarthost à ne pas créer de configuration en "Open Relay", qui permettrait à n'importe qui d'envoyer des mails à travers le smarthost, la sentence sera immédiate lorsque des spammeurs s'en apercevront. Réglez bien votre mynetwork, et sender_restrictions (par exemple avec Postfix).

Pour aller plus loin

Voici une liste d'outils assez pratique lorsque l'on configure ou que l'on cherche la cause d'un problème de délivrance sur un serveur mail :

Mail Tester (indispensable pour vérifier votre configuration)
MXToolbox (le couteau suisse des tests sur les serveurs mails)
Quelques conseils de Google

Quelques liens pour (essayer de) se faire retirer de la Blocklist :

Pour se faire dé-bannir par Microsoft (sans garanties...)
Pour se faire dé-bannir par Google (sans garanties)
Pour se faire débannir par Yahoo (sans garanties)
Pour se faire débannir par AOL (sans garanties)

Les programmes de monitoring de réputation :

Configurer un backup incrémental avec duplicity, rsync, et backupninja sous Debian

Mathieu — Tue, 09 Jun 2015 14:37:00 +0200

English version.

Introduction

Si vous savez ce qu'est un backup, vous devriez savoir qu'il y a plusieurs types de backups :

Un backup complet copie tous les fichiers, en espérant que votre disque de backup soit assez grand pour accueillir plus d'un backup.
Un backup incrémental commence par faire un backup complet, puis les fois suivantes n'enregistre que les "différences" sur les fichiers modifiés.

Évidemment, un backup complet est plus simple à restaurer, puisque ce sont les fichiers, et rien que les fichiers ; alors que le backup incrémental a un format de fichier spécial lui permettant de représenter les "diffs" à chaque sauvegarde. Mais considérant le gain d'un backup incrémental en bande passante, vitesse, et espace disque , votre solution pour un backup régulier devrait être le backup incrémental.

Les outils

Duplicity est un logiciel libre similaire à rdiff-backup. Duplicity permet de créer un backup incrémental. Duplicity peut également chiffrer les fichiers, pour pouvoir les envoyer en toute sécurité sur un service de stockage distant. Dans une configuration classique, Duplicity est utilisé conjointement avec rsyc pour optimiser les temps de transfert vers le stockage distant, mais vous pouvez très bien utiliser un disque de stockage local, un serveur FTP, ou un cloud Amazon E3 pour y envoyer vos sauvegardes. Comme le titre l'indique, dans cet exemple j'utiliserai rsync.

Et les bases de données ? Les bases de données ne peuvent pas être sauvegardées simplement en copiant les fichiers de données, car cela peut provoquer une corruptio de données, et vous aurez des bases inutilisables dans vos sauvegardes. Il nous faudrait donc un script qui dump toutes les bases de données avant de sauvegarder ces fichiers de dump via notre méthode de sauvegarde préférée.

Bonne nouvelle : backupninja sait faire tout cela. Backupninja est une sorte de "backup-master" : il est capable de récupérer des données depuis différentes sources (fichiers, bases de données...) et les envoyer à différentes destinations (backup simple, duplicity...), il suffit juste d'écrire les fichiers de configuration correspondants !

Dans cet exemple, nous utiliserons donc backupninja pour récupérer nos fichiers et nos bases de données, et les envoyer pour un backup incrémental Duplicity, stocké sur un serveur SSH distant, en utilisant rsync.

C'est parti !

Pré-requis

Une machine sous Debian que nous allons backuper, appelons-la production
- Un serveur de backup avec accès SSH (SSH est requis pour rsync mais vous pourriez avoir un simple serveur FTP), appelons-la backup
Savoir modifier des fichiers de configuration et relancer un service

Configurez le compte sur le serveur de backup

Pour pouvoir envoyer les sauvegardes vers le serveur backup via rsync, nous avons besoin de nous identifier sur ce serveur à partir de production sans spécifier de mot de passe.

Tout d'abord, travaillons en root sur production : sudo -s

Créez les clef SSH pour root : ssh-keygen -t rsa

Après avoir tapé la commande précédente, la clef publique va s'installer dans /root/.ssh/id_rsa.pub et la clef privée dans /root/.ssh/id_rsa

À présent, considérons backup, vérifiez que votre serveur SSH sur backup accepte l'authentification par clefs privées. Dans le fichier /etc/ssh/sshd_config, les lignes suivantes doivent apparaître (non commentées) :

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile     %h/.ssh/authorized_keys

Sinon, ajoutez-les et relancez le service ssh.

Maintenant, ajoutez l'utilisateur prod_server sur backup : useradd prod_server
Vous pourriez avoir envie changer son dossier home, je suppose que vous savez comment le faire.

Retour sur production, copiez la clef publique dans le fichier /home/prod_server/.ssh/authorized_keys de backup.
La méthode bourrin : scp /root/.ssh/id_rsa.pub root@backup:/home/prod_server/.ssh/authorized_keys
La méthode gentlemen : copiez-collez le contenu de production:/root/.ssh/id_rsa.pub à la fin du fichier backup:/home/prod_server/.ssh/authorized_keys

Si vous avez tout fait correctement, vous devriez pouvoir vous connecter en ssh depuis votre compte root de production sur le compte prod_server de backup sans spécifier de mot de passe.

Installez backninja (et ses amis)

Sur production, entrez la commande : sudo apt-get install backupninja duplicity rsync

Configurez le dump des bases de données

C'est parti, configurons backupninja !

Pour MySQL, copiez le fichier d'exemple à partir de /usr/share/doc/backupninja/examples/example.mysql dans le dossier /etc/backup.d/10-alldb.mysql et modifiez-le pour vos propres besoins (le fichier est simple et bien commenté).

databases   = all
backupdir   = /var/backups/mysql
hotcopy     = no
sqldump     = yes
compress    = yes
configfile = /etc/mysql/debian.cnf

Pour PostgreSQL, même chose ! Copiez le fichier /usr/share/doc/backupninja/examples/example.mysql dans le dossier /etc/backup.d/10-alldb.pgsql et modifiez les valeurs souhaitées.

backupdir = /var/backups/postgres
databases = all
compress = yes
format = plain

Pourquoi est-ce que j'utilise le préfixe 10- au début de mes fichiers ? Pour la même raison pour laquelle vous préfixez vos fichiers de configuration Nginx : pour gérer l'ordre de lecture. J'ai besoin de créer les dumps des bases de données avant de créer le backup des fichiers, sinon Duplicity enregistrera les fichiers de la veille, et les fichiers que nous venons de créer devront attendre le lendemain pour être sauvegardés ! Donc, les fichiers de configuration qui vont créer les dumps seront préfixé par 10- et les fichiers pour configurer le backup incrémental de Duplicity seront préfixés par 20-, par exemple.

Les dumps SQL seront stockés dans /var/backups/ selon ma configuration actuelle.

Configuration de Duplicity pour le backup incrémental

Comme tout à l'heure, copiez le fichier d'exemple : cp /usr/share/doc/backupninja/examples/example.dup /etc/backup.d/20-files.dup

Et modifiez les valeurs, en particulier la valeur desturl :

# Disable testconnect because we use desturl
testconnect = no

# You may change this if you are a partition-maniac
tmpdir = /tmp

[gpg]
# Using symetric encryption for archive files
# Note that an encryption method is mandaory, either with symetric or private keys
# Don't forget to note that password somewhere !
password = whateveryouwant

[source]
# Specify the paths to your files
include = /var/spool/cron/crontabs
include = /var/log
include = /var/mail
include = /var/www
include = /etc
include = /root
include = /home
include = /usr/local

# And to your database dumps !
include = /var/backups/mysql
include = /var/backups/postgresql

# There are some files we don't need
# Don't forget to add the tmpdir in the exclude list, if it was included in the previous paths !
exclude = /home/*/.gnupg
exclude = /var/cache/backupninja/duplicity
exclude = /tmp

[dest]
# Adjust these to your own taste
incremental = yes
increments = 15
keep = 30
keepincroffulls = all

# Specify the backup server crendentials
## desturl = file:///usr/local/backup
## desturl = rsync://user@other.host//var/backup/bla
## desturl = s3+http://
## desturl = ftp://myftpuser@ftp.example.org/remote/ftp/path
desturl = rsync://prod_server@backup//home/prod_server/data

# Only if you choose FTP
# ftp_password = whateveryouwant

Cette configuration utilise un chiffrement symétrique pour les archives sauvegardées. Si vous voulez mettre en place un chiffrement asymétrique, vous pouvez lire la documentation et adapter la configuration.

Configurez la fréquence des backups

Vous avez peut-être remarqué que backupninja a créé un cronjob dans /etc/cron.d/backupninja mais si vous ouvrez ce fichier, vous constaterez que le cronjob est lancé toutes les heures. Pourquoi ? Parce que le cronjob n'est utilisé que pour lancer le backup, qui vérifie si une mise à jour du backup est nécessaire avant de lancer réellement l'opération de backup. Pour modifier les heures et la fréquence des mises à jour, vous pouvez modifier le fichier /etc/backupninja.conf :

when = everyday at 01:00

Ajustez la valeur selon vos souhaits. Vous pouvez combiner plusieurs lignes, si vous voulez plusieurs dates de démarrage (en savoir plus).

Démarrez votre backup, et vérifiez son bon fonctionnement

C'est le moment de démarrer votre backup pour la première fois ! Si vous ne voulez pas attendre une heure pour que le cron se lance, vous pouvez lancer le backup immédiatement avec la commande backupninja -d -n

Si aucune erreur ne s'affiche pendant l'exécution, bravo ! Vous venez de configurer backupninja avec succès !

À présent, contrôlons que notre backup est bien arrivé : connectez-vous à backup et listez le fichiers dans le dossier /home/prod_server/data/

Vous devriez voir les fichiers d'index créés par Duplicity, vous ne pouvez pas les ouvrir sans utiliser quelques commandes :

Afficher le statut des "collections" : duplicity collection-status file:///home/prod_server/data
Lister les fichiers dans l'archive : duplicity list-current-files file:///home/prod_server/data
Restaurer le dernier backup dans un dossier précis duplicity restore file:///home/prod_server/data/ /home/prod_server/test-restore/ (si vous ne voyez des erreurs mais que les fichiers sont bien présents à la fin de l'exécution de la commande, c'est parce que Duplicity essaye de restaurer les atributs "prorpiétaire" des fichiers, et qu'il ne peut pas le faire si vous n'avez pas lancé la commande en root).

Vous devez avoir le programme Duplicity installé sur le serveur backup pour pouvoir utiliser ces commandes en mode shel sur backup.

Vous pouvez aussi lancer ces commandes sur le serveur production et accéder aux backups stockés sur backup en utilisant la desturl que vous avez configurée au lieu du préfixe file:// que vous utilisez quand vous lancez la commande sur backup.

Conclusion

Vous devriez maintenant être capables d'implémenter une solution complète de backup en utilisant backupninja.

J'espère que cet article vous a été utile, vous pouvez rédiger un commentaire via le formulaire ci-dessous si vous rencontrez des problèmes avec cette documentation.

Un serveur au régime : faites tourner un serveur complet dans un mouchoir de poche

Mathieu — Mon, 25 Nov 2013 07:15:00 +0100

Introduction

Ce n’est pas la période pour les régimes et pourtant aujourd’hui, dans un billet volontairement cryptique aux non-initiés, je vais vous dévoiler les quelques secrets qui permettent à des nerds invétérés de donner vie à des machines ridiculement pauvres en RAM. Pour la beauté du geste, mais pas que.

Je me souviens que l’on s’est souvent moqué de moi quand je disais qu’avec 512 mégas de RAM on pouvait faire tourner un serveur complet mail+ftp+web+sql. En remplaçant quelques programmes, vous pouvez parfaitement faire tourner votre application web standalone, un noeud de CDN performant, un miroir FTP, ou un relais mail.

Cet article va simplement vous présenter des alternatives, et terminer avec quelques astuces plus générales. Le but est de remplacer notre célèbre LAMP par des solutions moins gourmandes en mémoire.

Remplacer Apache

Pour remplacer Apache, nous avons le choix entre Nginx et Lighttpd (Lighty).

Lighttpd est le serveur le plus léger au monde. Sa structure est très simple, et l’impact d’une connexion en mémoire est très faible.

Nginx est un serveur qui consomme un peu plus au démarrage, mais qui utilise une gestion intelligente de ses connexions ouvertes pour optimiser son impact mémoire.

Inconvénients : oubliez les .htaccess, préparez-vous à faire un peu de configuration pour remplacer votre “a2enmod php5”, et changez vos habitudes pour redémarrer les services.

Remplacer MySQL

Ce n’est pas facile de remplacer MySQL, tellement le nombre de programme qui en dépendent est conséquent. Cependant, si c’est possible, n’hésitez pas une seconde, voici les deux alternatives “lowcost” possibles :

SQLite : une base SQLite est simplement un fichier qui est chargé en mémoire au moment où l’on veut lire dedans. Pas de démon résident, pas d’impact lorsque la base est inactive. Par contre, préparez vous à attendre un peu si votre base est conséquente : lire des données en n’utilisant que le cache disque, ça peut prendre du temps.

PostgreSQL : PostgreSQL est un peu le nouveau MySQL, mais en mieux. de faible impact mémoire au démarrage, doté de plus de fonctionnalités que MySQL et proposant de meilleures performances, il reste encore marginal mais a tout pour concurrencer les équivalents propriétaires comme Oracle. On peut l’utiliser dans un environnement limité, en configurant correctement les limites dans sa configuration.

Remplacer ProFTPd

Si vous proposez un hébergement, vous proposerez certainement un serveur FTP.

Si les utilisateurs du serveur sont des utilisateurs “de confiance” (ie : que vous connaissez), vous pouvez leur laisser utiliser le serveur SFTP fourni par le serveur SSH (à activer dans la configuration). De très faible impact mémoire, pour une meilleure sécurité et moins de configuration, le protocole SFTP est supporté par la majorité des clients FTP. C’est LA solution des flemmards pour mettre en place un serveur FTP.

Sinon, vous pouvez vous rabattre sur un VSFTPd, qui en plus de vous combler au niveau impact mémoire, vous comblera au niveau rapidité. Il gère aussi le FTPS.

Remplacer Postfix

Si vous n’utilisez pas la réception des mails et que vous ne faites que de l’envoi (avec ou sans smarthost), Exim vous comblera au moins autant que Postfix, vous proposant même sous Debian une interface de configuration “pour les nuls” : dpkg-reconfigure exim4-config.

Éviter la catastrophe

En cas de gonflement inattendu de la mémoire, et lorsque celle-ci commence à manquer, le système d’exploitation commence à sacrifier des programmes pour libérer de la RAM. C’est dommage, on aimerait éviter d’en arriver à de telles extrémités sur un serveur de production.

La solution est assez simple, bien qu’imparfaite : il suffit de rajouter de la SWAP. La SWAP est un fichier d’échange placé sur le disque dur, lorsque il n’y a plus de mémoire en RAM, une partie de la RAM est déchargée (ie copiée) sur la SWAP, pour laisser de la place aux programmes “actifs”. Bien entendu, cette mémoire déchargée devra être rechargée dès lors qu’un programme a besoin d’un bloc mémoire qui a été placé en SWAP, ralentissant le traitement à la vitesse des temps d’accès disque (pas cool).

Faire dormir tout le monde

Ce qui est pénible avec les serveurs, c’est la quantité de RAM qui est là, utilisée en permanence, pour finalement un seul pic d’utilisation. Si on pouvait récupérer la RAM des programmes qui n’interagissent pas avec l’extérieur, et ne les lancer que quand on en a besoin ? Inetd est fait pour ça !

Inetd c’est un “super démon” qui va écouter sur les ports demandés à la place des programmes, et qui va lancer les programmes pour traiter l’événement, dès lors qu’une connexion est ouverte sur un de ses ports d’écoute. On peut donc imaginer avoir un Lighttpd non lancé qui se fait réveiller lorsque Inetd reçoit une connexion sur le port 80. Lighttpd traite alors la requête et s’arrête immédiatement après, laissant la place pour d’autres programmes.

L’inconvénient ici vient des temps de traitement forcément plus longs qu’avec des démons résidents (démarrer le programme prend du temps).

Conclusion

Voilà, c’est à peu près tout, j’espère qu’avec ces petits changements dans votre configuration, vous aurez quelques pistes pour alléger votre serveur, si jamais l’expérience vous tente.

Le monitoring sous Debian avec Nagios et Munin (Puppet en guest star) : de A à Z - Partie 5 : NSCA

Mathieu — Sun, 13 Oct 2013 16:04:00 +0200

Voir l’ensemble des articles de la série — Voir l’article précédent : Munin.

Cet article est le dernier de la série.

Dans l’article précédent, nous avons vu comment configurer Munin pour qu’il collecte des données et affiche ses graphes. Il nous reste à présent à configurer la communication entre Munin et Nagios, grâce à l’agent NSCA.

Introduction

Tests passifs, tests actifs

Nagios distingue deux type de tests à effectuer sur les hôtes, par le biais de ses déclarations de services : les tests actifs et les tests passifs.

Les tests actifs sont les tests réalisés par Nagios via un de ses plugins : ça peut être le test d’un port ou le contrôle de la réponse d’un service. Ces tests sont synchrones (effectués à intervalle fixe).
Les tests passifs sont les tests dont les résultats sont reportés à Nagios par d’autres programmes : là ça sera NSCA. Ces tests sont asynchrones (effectués “quand on peut”, pas forcément régulièrement).

NSCA

NSCA est littéralement « Nagios Service Check Acceptor ». C’est un démon qui tourne en arrière plan, et qui va recevoir les résultats des tests passifs, pour le retransmettre à Nagios.

Pour plus de simplicité, NSCA sera installé sur la même machine que le serveur Maître de Nagios.

Munin <=> NSCA

Le serveur maître de Munin va communiquer à NSCA les résultats des tests grâce à la commande send_nsca, utilisant le protocole NSCA.

Pour encore plus de simplicité, nous allons supposer que le serveur maître de Munin et le serveur NSCA (et donc Nagios aussi) se trouvent sur la même machine (comme ça, pas besoin de chiffrer les communications entre Munin et NSCA).

NSCA <=> Nagios

NSCA va communiquer avec Nagios via un tube nommé, c’est à dire un fichier dans lequel il va écrire, et qui va être lu par Nagios à intervalle régulier.

On peut faire porter ce tube par une socket pour réaliser une installation de NCA et Nagios sur deux machines différentes, mais ce n’est pas le sujet de cet article.

Installation et configuration de NSCA

Installation

NSCA se trouve dans les dépôts : sudo apt-get install nsca

Configuration

La configuration de NSCA se trouve dans /etc/nsca.cfg. Voici les valeurs à retenir :

#Ne jouez pas à changer ça pid_file=/var/run/nsca.pid # Notre master Munin se trouve sur la même machine, donc on bind sur 127.0.0.1 et ça suffit server_address=127.0.0.1 # Il est important que cet utilisateur puisse écrire dans le tube nommé pour communiquer avec Nagios ! nsca_user=nagios # Ce fichier spécial devra aussi être mentionné dans la configuration de Nagios, et le nsca_user doit pouvoir y écrire command_file=/var/lib/nagios3/rw/nagios.cmd

Ouvrez le fichier /etc/init.d/nsca et vérifiez que le PIDFILE est le même que celui de la configuration :

PIDFILE="/var/run/nsca.pid"

Configuration de Munin

Ouvrez le fichier /etc/munin/munin.conf.

Normalement, vus avez déjà configuré un “contact” pour être avertit en cas de défaillance d’un service contrôlé par Munin. Nous allons à la suite en rajouter un second :

contact.nagios.command /usr/sbin/send_nsca -H localhost contact.nagios.always_send ok warning critical contact.nagios.max_messages 1

Petite information qui vous fera gagner une journée de travail : max_messages doit être à 1 sous Debian 7. Ceci parce que le NSCA des dépôts a été mis jour, et est devenu incompatible avec la version du protocole NSCA implémentée par Munin. On peut bidouiller NSCA pour corriger ça, mais la solution de contournement la plus simple est de n’envoyer qu’un message à la fois à NSCA.

Ici Munin enverra les résultats “OK”, “Warning” et “Critical” de ses module. Nous allons également faire en sorte qu’un Munin muet déclenche une erreur UNKNOWN chez Nagios, pour s’assurer que le “OK” correspond bien à un test “OK” et non à l’absence de “Warning” et de “Critical”.

Ok, on triche un peu. En fait, les tests de Munin sont synchrones. On a donc un mécanisme synchrone (Munin) qui va envoyer de manière synchrone les résultats au mécanisme asynchrone de collecte (NSCA). L’aspect synchrone va nous permettre de détecter le moment où on aurait dût recevoir un résultat, et alerter si ce n’a pas été le cas.

Configuration de Nagios

Communication avec NSCA

Ouvrez le fichier de configuration /etc/nagios3/nagios.cfg et vérifiez que la ligne suivante est bien présente et dé-commentée :

command_file=/var/lib/nagios3/rw/nagios.cmd

Les services

Si vous avez déjà redémarré les services après chaque modification de la configuration, vous pourrez voir dans les logs de Nagios les erreurs suivantes :

[1381670602] Warning: Passive check result was received for service 'some service' on host 'hostname.ext', but the service could not be found!

La bonne nouvelle c’est que Nagios reçoit les notifications de NSCA !

La mauvaise c’est qu’il ne peut pas le lier à un service et à un hôte, parce qu’ils ne sont tout simplement pas déclarés. Il va nous falloir déclarer un service Nagios pour chaque service Munin que nous lui transmettons, sinon celui-ci ne sera pas capable de le traiter.

Créez le fichier /etc/nagios3/conf.d/services/munin-services.cfg et placez à l’intérieur la configuration suivante :

# generic service template definition define service{ name generic-munin-service ; The 'name' of this service template use generic-service check_command return-unknown!"No Data from passive check" active_checks_enabled 0 ; Active service checks are disabled check_freshness 1 freshness_threshold 360 flap_detection_options n max_check_attempts 2 register 0 ; DONT REGISTER THIS DEFINITION - ITS NOT A REAL SERVICE, JUST A TEMPLATE! ;first_notification_delay 6 ; Delay first notification for false positives (will execute 2 checks : munin sends 1 check every 5 minutes) } define service { hostgroup_name munin service_description Disk latency per device :: Average latency for /dev/sda use generic-munin-service notification_interval 0 ; set > 0 if you want to be renotified } define service { service_description Disk latency per device :: Average latency for /dev/sdb use generic-munin-service notification_interval 0 ; set > 0 if you want to be renotified } define service { hostgroup_name munin service_description Disk usage in percent use generic-munin-service notification_interval 0 ; set > 0 if you want to be renotified } define service { hostgroup_name munin service_description Inode usage in percent use generic-munin-service notification_interval 0 ; set > 0 if you want to be renotified } define service { hostgroup_name munin service_description File table usage use generic-munin-service notification_interval 0 ; set > 0 if you want to be renotified } define service { hostgroup_name munin service_description eth0 errors use generic-munin-service notification_interval 0 ; set > 0 if you want to be renotified } define service { hostgroup_name munin service_description Exim Mailqueue use generic-munin-service notification_interval 0 ; set > 0 if you want to be renotified }

Ce fichier est bien évidemment à compléter selon les plugins et les checks que vous avez activé dans Munin. Le service_description est le nom complet du service dans Munin.

La configuration du template générique nous assure qu’une erreur “UNKNOWN : No data from passive check” sera retournée en cas d’absence de résultat après le délai du “freshness_threshold”, avec 2 essais avant d’alerter du problème.

Les groupes d’hôtes

Les plus attentifs d’entre-vous ont remarqué la présence d’un hostgroup dans la configuration, mais nous ne l’avons pas encore déclaré. Allons-y, rajoutez dans le fichier /etc/nagios3/conf.d/groups.cfg :

# Hostgroup for Munin define hostgroup { hostgroup_name munin alias Munin reporting clients }

Les hôtes

Maintenant qu’on a le hostgroup, il ne reste plus qu’à modifier vos fichiers /etc/nagios3/conf.d/hosts/*.cfg pour rajouter le hostgroup sur les hôtes sur lesquels munin-node est installé.

Débuggage

En principe, après avoir redémarré tous les services, vous devriez recevoir assez vite les notifications de NSCA et voir passer vos indicateurs du gris vers le vert dans Nagios.

Si ce n’est pas le cas et que ces derniers passent au orange, c’est qu’il y a un problème de communication entre Nagios et Munin. Mon problème principal a été le non démarrage de NSCA au démarrage de la machine, pour de histoires de PID que le script de démarrage n’arrivait à écrire ou à supprimer.

Il arrive aussi que le tube nommé soit inaccessible en écriture à l’utilisateur qui lance NSCA, vérifiez bien que l’utilisateur nagios est celui qui fait tourner à la fois Nagios et NSCA.

Enfin, pour vérifier que le problème ne vient pas d’une mauvaise configuration de Nagios, faites un envoi de données “manuellement” avec la commande send_nsca :

echo -e "monhote.ext\tNom complet du service Munin\t1\t0\n\n" | /usr/sbin/send_nsca -H localhost

Pour conclure

En conclusion, nous avons terminé notre installation de Munin, Nagios, et NSCA ! Munin communique à présent ses alertes à Nagios, et Nagios est capable d’alerter si ces alertes ne sont pas remontées. Le reste est dans les billets précédents !

N’hésitez pas à me faire part dans les commentaires des problèmes que vous pourriez rencontrer en déroulant cette suite d’articles, ou à me corriger si vous constatez des erreurs dans la série d’article.

Voir l’ensemble des articles de la série.

Le monitoring sous Debian avec Nagios et Munin (Puppet en guest star) : de A à Z - Partie 4 : Munin

Mathieu — Mon, 19 Aug 2013 22:29:00 +0200

Voir l’ensemble des articles de la série — Voir l’article précédent : Puppet.

Dans l’article précédent, nous avons vu une manière simple de configurer Puppet pour des opérations de réplication base de la configuration.

Dans cette partie nous allons détailler l’installation et la configuration de Munin et de ses plugins, en utilisant bien sûr notre Puppet fraîchement installé.

Principe

Munin est basé tout comme Nagios et Puppet sur le modèle maître-esclave : le “master” Munin va récupérer à intervalle régulier les données des “nodes” et remplir des fichiers contenant les données reçues. Ces fichiers sont au format RRD, qui est un standard utilisé par beaucoup de logiciels de collecte de données.

Nous allons donc devoir configurer d’une part le “master” et ensuite les “nodes”. Pour les nodes, nous utiliserons Puppet pour répliquer la configuration.

Munin, tout comme Nagios, a une architecture modulaire basée sur des plugins. Cela veut dire que le programme principal ne fait que de la collecte et de la transmission de données. Toutes les données collectées sont en réalité fournies par des plugins, qu’il va falloir configurer un par un. Rassurez vous, la plupart des plugins possèdent déjà une configuration par défaut.

Pour la suite, je vais supposer que le serveur accueillant le master munin est nommé “master” sur le réseau et ceux accueillant les nodes “node01”, “node02”, etc. Je vais aussi supposer que vous avez correctement installé Puppet sur l’ensemble des futurs nodes Munin.

Note importante : les données qui sont échangées entre les nodes Munin et le Master ne sont pas chiffrées. Si c’est un problème pour vous, vous devriez étudier attentivement la configuration TLS pour Munin.

Le “master”

L’installation du master Munin ne présente pas de difficultés particulières : sudo apt-get install munin

Munin possède une interface de visualisation de ses graphes, mais il faut configurer le serveur web pour y accéder. La configuration pour Apache fournie avec le paquet est prête à être installée dans /etc/munin/apache.conf

Configuration générale

Le fichier de configuration principal se trouve dans /etc/munin/munin.conf

La configuration par défaut n’a pas besoin d’être beaucoup retouchée. Renseignez toutefois les adresses de contact, par exemple :

contact.root.command mail -s "Munin notification" root@localhost

Vous pouvez ajouter plusieurs de ces lignes, avec le nom d’utilisateur et l’adresse mail que vous souhaitez.

Configuration des nodes

Vers la fin du fichier /etc/munin/munin.conf , vous trouverez un exemple de configuration pour un node en local. Nous allons rajouter les nôtres !

Tout d’abord, les nodes en eux même, il s’agit simplement de les déclarer à la suite de cette façon :

[node01] address 172.16.0.1 use_node_name yes [node02] address 172.16.0.2 use_node_name yes [node03] address 172.16.0.3 use_node_name yes

Évidemment, changez l’adresse IP mentionnée ici par l’adresse IP de vos nodes à vous.

Configuration des groupes de nodes

Si votre parc est hétérogène, vous aurez rapidement très envie de faire des groupes pour rassembler vos hôtes et naviguer facilement dans les graphes.

Pour cela, toujours dans le fichier /etc/munin/munin.conf, il suffit de rajouter un “pseudo-hote” de cette façon :

[monparc;Totals] # Pour les graphes totaux update no # Pas de collecte de données sur cet hôte [monparc;] # Groupement des nodes node_order Totals node01 node02 node03

N’oubliez pas de relancer Munin après avoir modifié la configuration : service munin restart

Les “nodes”

D’abord la configuration pour un node, et après on s’occupera de la réplication de la configuration avec Puppet.

Configuration générale

Le nodes n’ont besoin que de très peu de configuration, pratiquement tout est fait par les plugins, et la récupération des données est faite par le Master.

Dans le fichier /etc/munin/munin-node.conf, renseignez si besoin le nom du node dans le paramètre host_name :

host_name node01

Précisez qui sera autorisé à venir collecter les données via le paramètre allow ou cidr_allow si vous autorisez tout votre sous-réseau (note : fonctionne aussi en ipv6) :

allow ^172\.16\.0\.200$ # On suppose que le Master est à l'adresse 172.16.0.200 cidr_allow 172.16.0.0/16 # Là on autorise carrément tout le sous-réseau /16

Enfin, vérifiez bien que le node est en écoute sur toutes les adresses :

bind *

N’oubliez pas de relancer munin-node après avoir changé la configuration : service munin-node restart

Les plugins

L’ensemble des plugins disponibles réside dans le dossier /usr/share/munin/plugins/, il est fortement déconseillé de les lancer directement.

Pour activer un plugin, il suffit de créer un lien symbolique dans le dossier /etc/munin/plugins/, et de relancer le démon munin-node. par exemple :

ln -s /usr/share/munin/plugins/apt /etc/munin/plugins/apt

service munin-node restart

Pour tester l’exécution d’un plugin, il suffit de lancer la commande munin-run suivi du nom du plugin. Le plugin doit être activé et c’est le nom du lien symbolique qui est à spécifier lors de l’appel à munin-run. munin-run a d’autres options intéressantes, comme par exemple “munin-run <nomduplugin> config”, qui permet de lister tous les paramètres spécifiques à un plugin.

Certains plugins prennent des paramètres directement depuis le lien symbolique. Par exemple le plugin “ping” se nomme “ping_” mais ne fonctionnera pas si votre lien symbolique s’appelle “ping_”. Le nom du lien symbolique doit préciser l’hôte à pinguer :

ln -s /usr/share/munin/plugins/ping_ /etc/munin/plugins/ping_ipv4.google.com

À noter que ça marche aussi pour un ping en ipv6 :

ln -s /usr/share/munin/plugins/ping_ /etc/munin/plugins/ping6_ipv6.google.com

De la configuration peut être nécessaire pour faire remonter les alertes des plugins. Dans le dossier /etc/munin/plugins-conf.d/ se trouve la configuration des plugins. je vous conseille de faire un fichier de configuration par plugin, nommé comme le plugin présent dans /etc/munnin/plugins/. On peut y configurer l’ensemble des paramètres retournés par la commande munin-run <nomduplugin> config à l’exception qu’il faut rajouter “env.” devant et préciser le nom du plugin ciblé. Par exemple :

[ping_*] env.ping_warning 0.030 env.ping_critical 0:0.100 env.packetloss_warning 1 env.packetloss_critical 10

Et comme d’habitude, pour aller plus loin, rien de tel qu’un petit tour dans /usr/share/doc/munin-node/

Un coup de Puppet magique !

Ça y est, on est calé sur la configuration des nodes ! Et si on répliquait ?

Reprenons les fichiers que nous avons préparés dans la partie précédente. Le fichier /etc/puppet/manifests/classes/munin.pp contient le prototype pour notre configuration. nous allons rajouter dans ce fichier de quoi paramétrer directement les nodes Munin :

class munin { # S'assurer que munin-node soit bien toujours à la dernière version des dépôts disponible package {'munin-node': ensure => 'latest', } # S'assurer que le démon munin-node tourne sur la machine service {'munin-node': ensure => 'running', enable => 'true', hasrestart => 'true', require => Package['munin-node'], } # En cas de modification de la configuration, redémarre munin-node file { '/etc/munin/munin-node.conf': ensure => 'file', notify => Service['munin-node'], # this sets up the relationship mode => 644, owner => 'root', group => 'root', require => Package['munin-node'], content => template('munin/munin-node.conf.erb'), # Ça on explique juste après } # On configure un plugin qui n'est pas par défaut, histoire de dire qu'on l'a fait # Le lien symbolique file { '/etc/munin/plugins/apt': ensure => 'link', group => '0', mode => '777', owner => '0', target => '/usr/share/munin/plugins/apt', notify => Service['munin-node'], # Ah oui, si on change ce fichier, on redémarre munin-node } # La configuration file { '/etc/munin/plugin-conf.d/apt': ensure => 'present', group => '0', mode => '644', owner => '0', content => "[apt]\nenv.pending.warning 0:0", notify => Service['munin-node'], # Là aussi on redémarre } }

Parlons de template('munin/munin-node.conf.erb'). Puppet nous permet d’utiliser des templates de configuration pour éviter d’avoir à fournir tout le contenu du fichier de configuration au milieu des règles Puppet. C’est le cas pour le fichier /etc/munin/plugin-conf.d/apt, mais pour ce fichier qui est volumineux et nécessite l’emploi d’une variable, créez le dossier munin dans le dossier /etc/puppet/templates/ et remplissez le avec le contenu suivant :

# # Example config-file for munin-node # log_level 4 log_file /var/log/munin/munin-node.log pid_file /var/run/munin/munin-node.pid background 1 setsid 1 user root group root # Regexps for files to ignore ignore_file [\#~]$ ignore_file DEADJOE$ ignore_file \.bak$ ignore_file %$ ignore_file \.dpkg-(tmp|new|old|dist)$ ignore_file \.rpm(save|new)$ ignore_file \.pod$ host_name <%= @hostname %> allow ^172\.16\.0\.200+$ host * port 4949

Notez la variable @hostname employée dans le fichier, et qui doit être déclarée dans le node Puppet (voir ci-après).

Finalement, n’oubliez pas de créer un “node” Puppet dans le dossier /etc/puppet/manifests/nodes/ pour chaque node Munin, et de le configurer comme dans l’exemple :

node 'node01' { $hostname = 'node01' include munin }

Sinon la configuration ne sera tout simplement pas propagée par Puppet.

Pour conclure

Nous avons terminé notre petit tour de la configuration de Munin. Nous avons répliqué les nodes Munin avec Puppet, mais il nous manque encore quelque chose pour terminer le travail : pour l’instant notre Nagios est toujours muet et les alertes de Munin vous parviennent, mais ne sont pas centralisées dans Nagios.

C’est l’objet de la dernière partie : NSCA. Nous terminerons la configuration de Nagios pour mettre en place des contrôles passifs, et nous ferons le lien entre Munin et Nagios, comme “par magie”.

Lire la partie suivante : NSCA.

Voir l’ensemble des articles de la série.

Le monitoring sous Debian avec Nagios et Munin (Puppet en guest star) : de A à Z - Partie 3 : Puppet

Mathieu — Sat, 17 Aug 2013 16:00:00 +0200

Voir l’ensemble des articles de la série — Voir l’article précédent : Nagios.

Dans l’article précédent, nous avons vu comment écrire une configuration de base pour Nagios.

Dans cette partie, je vais aborder un sujet un peu transverse mais nécessaire à la création de notre solution d’ensemble : Puppet.

Introduction

Puppet est un logiciel de gestion de configuration. C’est à dire qu’il permet de répliquer et conserver à l’identique un ensemble de paramètres (des fichiers de configuration) sur un ensemble de machines.

Puppet a été créé pour un besoin simple : répliquer de la configuration à grande échelle sur un ensemble de machines, et en assurer la consistance. Nous allons principalement l’utiliser pour répliquer notre configuration de Munin sur l’ensemble des machines du parc, pour faciliter le déploiement de notre solution de monitoring.

Puppet fonctionne sur le modèle maître-esclaves : un serveur principal va contenir l’ensemble des paramètres à répliquer, et des serveurs esclaves vont interroger le serveur maître pour récupérer leur configuration. Il est possible de configurer le maître afin de différencier la configuration fournie à chaque esclave.

La communication entre le maître et ses esclaves est chiffrée et signée (le maître connaît ses esclaves, les esclaves connaissent leur maître), évitant que des informations sensibles ne se baladent sur le réseau, ou ne soit fournies accidentellement à des tiers.

Éléments en présence

Nous allons considérer les éléments suivants :

Le maître, aussi appelé PuppetMaster, est la machine qui va stocker les configurations à répliquer et fournir ce dont ellesont besoin aux machines esclaves.
Les machines esclaves, ou “clients Puppet”, sont les machines sous le contrôle du PuppetMaster, elles vérifient périodiquement auprès du PuppetMaster si leur configuration a besoin d’être mise à jour et appliquent les directives fournies par le PuppetMaster.

Pour ce tutoriel, nous allons considérer deux machines : le PuppetMaster que je vais appeler “master” et une machine cliente que je vais appeler “slave01”.

Je suppose que les machines “master” et “slave01” sont correctement mises en place dans le parc (qu’elles sont présentes dans le fichier /etc/hosts ou qu’elles ont un enregistrement DNS valide). Je suppose également que le FQDN des machines est correct (mis en place dans /etc/hostname ou avec la commande hostname -b).

Installation du Maître et de l’Esclave

Installation du Maître

À noter que dans le cas de la configuration qui est décrite, le maître ne sera pas son propre esclave. Il est néanmoins possible de gérer certains aspects de la configuration du maître via le maître lui-même en effectuant après l’installation du maître l’installation d’un esclave sur la même machine (mais attention aux migraines).

Sous Debian, Puppet est dans les dépôts. Pour installer le maître il suffit de taper : sudo apt-get install puppetmaster

Pour des raisons de sécurité, le PuppetMaster n’est pas configuré pour se lancer au démarrage de la machine. Éditez le fichier /etc/defaults/puppetmaster et placez la variable START à “yes”.

Lancez ensuite le serveur maître de Puppet avec la commande service puppetmaster start

Installation de l’esclave

De la même manière que le maître, lancez sur l’esclave : sudo apt-get install puppet

Comme pour le PuppetMaster, il faut préciser à l’esclave Puppet qu’il doit se lancer au démarrage de la machine : éditez /etc/defaults/puppet et placez la variable START à “yes”.

Ouvrez à présent le fichier de configuration /etc/puppet/puppet.conf et rajoutez la ligne suivante dans la section [main] :

server=master

J’utilise ici le domaine court (“master”) en supposant que celui-ci se résout correctement, mais vous pouvez mettre l’adresse IP du serveur “master” ou son FQDN à la place

C’est le moment d’essayer notre configuration ! Lancez la commande :

sudo puppetd --test --waitforcert 60

Si tout va bien, l’esclave va interroger le maître pour récupérer sa configuration. Comme c’est la première fois qu’il le fait, l’esclave va attendre que son certificat soit signé par le maître, qui le reconnaîtra alors comme un de ses esclaves.

Pour débloquer la situation, lancez la commande suivante sur le maître :

puppet cert --list

Vous devriez alors voir une liste de certificats en attente de signature. Toujours sur le maître, signez le certificat de votre esclave :


puppet cert --sign slave01

Sur l’esclave, la situation se débloque, et il vous informe que son certificat a été signé, tout est prêt !

Lancez finalement le démon Puppet sur l’esclave :

service puppet start

Le lancement du démon est nécessaire pour une propagation automatique des opérations que nous allons faire sur le maître. Un lancement manuel de la mise à jour de l’esclave peut cependant être fait avec la commande puppetd --test .

Comment ça marche ?

Sur le Maître, le point d’entrée principal de la configuration est /etc/puppet/manifests/site.pp

Le répertoire /etc/puppet/templates/ sert à stocker les templates de configuration qui pourront être lu par le moteur de Puppet (plus pratique de fournir le chemin vers un fichier template plutôt que de renseigner le contenu du fichier au milieu des règles de Puppet).

Le répertoire /etc/puppet/modules/, oubliez le pour l’instant.

Notre modèle de configuration pour la suite

Comme nous ne souhaitons pas mettre TOUTE la configuration dans /etc/puppet/manifests/site.pp, nous allons créer des répertoires dans le dossier manifests et inclure les fichiers qui sont présents dans ces répertoires, histoire de ranger un peu.

Créez les dossiers classes et nodes dans le dossier manifests .

Le dossier classes contiendra les éléments de configuration génériques, potentiellement paramétrables, que nous allons appliquer à nos esclaves.

Dans le dossier nodes, je vous conseille de créer un fichier par esclave, afin de personnaliser efficacement les classes requises pour chacun des esclaves.

Le fichier /etc/puppet/manifests/site.pp contiendra donc les appels aux fichiers présents dans ces répertoires :

# import many manifest files with node definitions import 'classes/*.pp' import 'nodes/*.pp'

Et nous auront donc dans le dossier /etc/puppet/manifests/classes un fichier munin.pp qui ressemblera à ça :

class munin { ... }

Et dans le dossier /etc/puppet/manifests/nodes un fichier slave01.pp qui ressemblera à ça :

node 'slave01' { $hostname = 'slave01' include munin }

C’est tout ! La configuration des esclaves pour servir de nœuds Munin via Puppet sera détaillé dans le prochain article.

À noter : La commande “import” de Puppet ne fait que déclarer les fichiers à lire, la commande “include” exécute la classe et donc applique effectivement la configuration du fichier.

Pour aller plus loin avec Puppet

Pour aller plus loin avec Puppet, vous pouvez lire la documentation issue du site de Puppetlabs.

Pour conclure

Nous avons posé les bases de notre solution de monitoring, notre serveur Nagios est en place, et Puppet est prêt à répliquer la configuration des nœuds Munin. Il nous reste à créer cette configuration, et à effectuer le lien entre le Master Munin et Nagios, pour que les alertes puissent remonter.

Dans le billet suivant, nous détaillerons la configuration des nœuds Munin avec Puppet et la configuration du Master Munin pour les alertes.

Lire la partie suivante : Munin.

Voir l’ensemble des articles de la série.

Le monitoring sous Debian avec Nagios et Munin (Puppet en guest star) : de A à Z - Partie 2 : Nagios

Mathieu — Sun, 07 Jul 2013 19:59:00 +0200

Voir l’ensemble des articles de la série — Voir l’article précédent : Introduction.

Dans l’épisode précédent, nous avons vu les généralités d’usage sur le monitoring, Nagios, et Munin.

Dans cette partie, je vais tenter de détailler la réalisation d’une configuration fonctionnelle de Nagios, avec quelques sondes, pour servir de base pour la suite.

Installation de Nagios

Je travaille sous Debian GNU/Linux par habitude. Avec ce système d’exploitation, il est très facile d’installer Nagios :

sudo apt-get install nagios3

Attention : la configuration pour Nagios ne s’écrit pas de la même façon selon la version majeure considérée. Ici pour la version 3, les fichiers de configuration seront différents de ceux pour Nagios 2, pensez à bien vérifier la version des exemples que vous copiez-collez sur Internet.

Nagios s’administre depuis une interface Web ; pour pouvoir y accéder, le paquet de Nagios installe automatiquement les dépendances permettant à un serveur Web de tourner (Apache 2 par défaut), mais vous pourriez avoir envie de faire autrement. Vérfiiez alors que vous avez bien un serveur web installé pour pouvoir faire tourner Nagios en CGI (python).

Nagios installe par défaut un ensemble de plugins pour les sondes mais pas seulement. Nagios est très modulaire, et permet de faire beaucoup de chose. Si vous avez besoin des plugins supplémentaires, ceux-ci sont dans les paquets nagios-plugins-* .

Par défaut, après l’installation Nagios est accessible à l’URL http://votreserveur/cgi-bin/nagios3/status.cgi. Le login et le mot de passe sont à changer avec la commande suivante htpasswd /etc/nagios3/htpasswd.users leloginsouhaite.

Où est la configuration ?

Le premier réflexe après avoir installé un logiciel, aussi automatisé que soit l’installation, c’est de regarder dans /etc/ si il y a pas un ou plusieurs fichiers de configuration.

Gagné, il y a /etc/nagios3/ et /etc/nagios-plugins/ .

Dans /etc/nagios3/ il y a la configuration générale de nagios : les hosts et les services à surveiller, l’interaction avec les systèmes externes, les personnes à prévenir en cas d’accident, etc.

Dans /etc/nagios-plugins/, il y a la configuration du comportement des plugins. Je m’en sers principalement pour avoir de la documentation sur les plugins disponibles et leurs arguments, mais vous pourriez en avoir besoin pour modifier le comportement d’un plugin, ou créer le vôtre.

C’est quoi ce bordel…

Si vous commencez à plonger dans la configuration de /etc/nagios3, vous allez vite déchanter : il y a des fichiers de configuration aux noms pas très évocateurs, de services par défaut et génériques qui ne veulent rien dire. Par de panique, on va vous aider.

Le point d’entrée de la configuration dans Nagios est le fichier /etc/nagios3/nagios.cfg. Pour des raisons évidentes, la configuration de Nagios n’est pas intégralement présente dans ce fichier. Nagios inclut tous les fichiers qui se trouvent dans le dossier /etc/nagios3/conf.d/ (et récursivement dans les sous-dossiers).

Les hôtes

Les hôtes dans Nagios sont les machines à surveiller. Ce sont des éléments identifiés par leur nom. Il peut y avoir des hotes “virtuels” qui ne correspondent pas à une machine en particulier mais à un ensemble de résultat provenant de sondes que vous pouvez configurer.

La configuration par défaut de Nagios définit un hôte générique. Cet hôte n’est pas affiché dans l’interface car c’est un “template” de configuration. Vous faites “hériter” vos hôtes de ce service générique qui contient tout ce dont la plupart des hôtes ont besoin, et vous y rajoutez votre grain de sel.

La configuration des hôtes dans Nagios se fait dans /etc/nagios3/conf.d/. je vous conseille de créer un dossier /etc/nagios3/conf.d/hosts/ et de créer ensuite un fichier par hôte, par commencer. Une fois que vous serez plus à l’aise avec le concept d’hôte générique, vous pourrez faire vos propres hôtes génériques, et factoriser un peu votre configuration.

Les services

Les services dans Nagios sont les appels aux sondes que vous allez définir. Ces sondes sont déclarées dans les fichiers de configuration de /etc/nagios-plugins/config/ pour pointer vers des exécutables (généralement en Perl ou en Python) présents dans le répertoire /usr/lib/nagios/plugins/, qui vont réaliser effectivement les tests.

Je vous conseille, pour définir vos services, de créer le dossier /etc/nagios3/conf.d/services/ et placer un fichier par service à l’intérieur.

Les sondes des services peuvent prendre des arguments. Le plus courant est de leur donner (implicitement) l’adresse de l’hôte à tester, mais on peut aussi passer explicitement des arguments, comme par exemple le port à tester. (Si jamais vous avez déplacé le port d’écoute de SSH. Comment ça vous l’avez pas fait ?)

Pour ceux qui en ont, les arguments des sondes sont déclarés dans /etc/nagios-plugins/config/.

Les groupes

Voilà le point central de votre configuration : les groupes. Les groupes sont déclarés dans /etc/nagios3/config/groups.cfg.

Un groupe dans Nagios est un moyen d’appliquer un ensemble de services à un hôte “d’un coup”. En gros, vous avez trois moyens d’attacher vos services à vos hôtes :

Quand vous déclarez vos hôtes, vous mentionnez explicitement les services qu’il doit posséder.
Quand vous déclarez les services, vous mentionnez explicitement les hôtes sur lesquels le service doit s’appliquer
Vous déclarez vos “groupes”, qui sont des ensembles de services, prêt à être appliqués à vos hôtes, vous spécifiez à quels groupes le service appartient, et vous spécifiez les hôtes présents dans le groupe.

Dans la suite, nous appliquerons la troisième solution.

Un petit exemple pour commencer

Sans commentaires, voici un petit exemple :

Groupes

/etc/nagios3/groups.cfg :

# A list of your web servers define hostgroup { hostgroup_name http-servers alias HTTP servers members host1 ; Link host to hostgroup } # A list of your ssh-accessible servers define hostgroup { hostgroup_name ssh-servers alias SSH servers members host1,host2 ; Link host to hostgroup }

Hôtes

/etc/nagios3/conf.d/hosts/host1.cfg :

define host { use generic-host ; Name of host template to use host_name host1 alias host1 address 192.168.1.11 ; Replace with your real host1 address ! }

/etc/nagios3/conf.d/hosts/host2.cfg :

define host { use generic-host ; Name of host template to use host_name host2 alias host2 address 192.168.1.12 ; Replace with your real host2 address ! }

Services

/etc/nagios3/conf.d/services/ssh.cfg :

# check that ssh services are running define service { hostgroup_name ssh-servers ; Link service to hostgroup service_description SSH check_command check_ssh_port!22 use generic-service notification_interval 0 ; set > 0 if you want to be renotified }

/etc/nagios3/conf.d/services/http.cfg :

# check that ssh services are running define service { hostgroup_name http-servers ; Link service to hostgroup service_description HTTP check_command check_http use generic-service notification_interval 0 ; set > 0 if you want to be renotified }

Toutes les sondes que vous voulez !

Dans l’exemple ci-dessus, j’ai utilisé deux sondes génériques : check_ssh_port et check_http. Toutes les sondes disponibles sont déclarées dans /etc/nagios-plugins/conf/, ces sondes se présentent sous la forme de “commandes” que l’on peut utiliser moment de la déclaration des services.

Les sondes déclarées appellent en général les exécutables qui se trouvent dans /usr/lib/nagios/plugins/. Souvent, plusieurs sondes sont déclarées pour un même exécutable, mais avec des paramètres différents (par exemple check_ssh et check_ssh_port qui permet de spécifier le port en argument).

Pour afficher les paramètres déclarés par les sondes, vous pouvez éditer les fichiers de configuration présents dans /etc/nagios-plugins/conf/.

Pour déclarer vos propres sondes à partir des exécutables, vous pouvez afficher les arguments disponible pour les exécutables de /usr/lib/nagios/plugins/ en lançant simplement le fichier exécutable avec le paramètre --help.

Les alertes

Pour l’instant notre Nagios est muet. Il peut alerter sur l’interface web, mais ne vous envoie pas de mails pour se plaindre que l’un des services est tombé.

Les alertes dans Nagios se configurent dans /etc/nagios3/conf.d/contacts.cfg, dans ce fichier sont définis les personnes à contacter en cas de problème, et quels sont les types d’alertes à recevoir par ces personnes.

Vous pouvez prendre exemple sur le contact par défaut pour créer vos propres contacts :

define contact { contact_name root alias Root service_notification_period 24x7 host_notification_period 24x7 service_notification_options w,u,c,r host_notification_options d,r service_notification_commands notify-service-by-email host_notification_commands notify-host-by-email email root@localhost }

N’oubliez pas de rajouter vos nouveaux contact au groupe de contact de Nagios :

define contactgroup { contactgroup_name admins alias Nagios Administrators members root }

Une configuration plus fine peut être réalisée au niveau des alertes, ou de l’escalade des alertes, suivez ce lien pour en savoir plus : Notifications Escalations.

Pour conclure

En guise de conclusion et pour aller plus loin, je vous conseille de faire comme vous en avez l’habitude sous Debian : lire les documentations qui sont incluses avec le paquet dans /usr/share/docs/nagios*.

Dans le prochain billet de cette série, je détaillerai l’installation et la réalisation d’une configuration simple pour Puppet, qui nous servira pour pouvoir installer facilement Munin sur l’ensemble des machines du parc.

Ah oui, n’oubliez pas de relancer le service nagios3 après avoir changé la configuration pour l’appliquer !

Lire la partie suivante : Puppet.

Voir l’ensemble des articles de la série.

Le monitoring sous Debian avec Nagios et Munin (Puppet en guest star) : de A à Z - Partie 1 : introduction

Mathieu — Thu, 04 Jul 2013 19:33:00 +0200

Voir l’ensemble des articles de la série.

Le monitoring. Graal des administrateurs système dès qu’un parc de machines commence à se constituer. Avec ce petit guide, vous allez découvrir que même avec seulement trois machines, on peut faire du monitoring. Même avec des machines mobiles ou pas toujours allumées, on peut faire du monitoring. Même avec les machines des clients, on peut faire du monitoring.

Pour pouvoir intervenir en cas de problème, il faut déjà savoir qu’il y a un problème, c’est le but du monitoring.

Cas d’étude

Vous gérez un parc. Ça peut être vos propres machines, ou les machines de vos clients. Vous pouvez avoir des serveurs ou des postes de travail, ces machines ne sont pas forcément toujours allumées, mais quand elles fonctionnent il faut avoir un retour sur leur état de santé. Vous aimeriez bien centraliser tout ça, mais vous ne savez pas comment faire. Voici comment.

Définitions / Présentations

Lorsqu’on parle de monitoring, on parle bien entendu de surveillance du système. Mais pour s’assurer de l’état du système, il faut deux choses :

Un collecteur (“node”), qui va au moyens de différentes sondes remonter les informations brutes sur les composants du système à surveiller. Ça peut être très bas niveau la température du CPU, ou une sonde élaborée comme le temps de réponse à un ping. Dans tous les cas, le collecteur seul ne suffit pas à dire “je fais du monitoring”.

Le concentrateur (“master”), qui va récupérer les informations du collecteur, et générer les alertes, le concentrateur va pouvoir vous afficher une vue synthétique de l’ensemble des machines que vous surveillez.

Dans ce petit guide, le collecteur sera Munin (en partie), et le concentrateur sera Nagios 3 (en partie). Je dis “en partie” parce que tout n’est pas aussi simple, et que Nagios et Munin vont assurer des rôles complémentaires étant chacun dans leur domaine à la fois “collecteur” et “concentrateur”.

Munin : le surveillant dans la cour

Munin est à la base un collecteur, c’est à dire qu’il va, au moyens de sondes déployées sur les postes à surveiller (“munin-node”), écrire des fichiers RRD. Ces fichiers pourront ensuite être exploités par un concentrateur (“munin” tout court) pour dessiner des graphes (“munin-graph”) et/ou envoyer des alertes à des systèmes externes.

Nagios : le mirador

Même si on peut installer un client Nagios servant de collecteur sur les postes à surveiller, Nagios n’a pas pour vocation d’observer directement les systèmes. Il est prévu pour effectuer des sondages “externes” des systèmes (tel port est-il ouvert, tel service répond-il correctement…).

De ce fait, Nagios va être limité dans les accès au système (comment remonter des alertes sur la température du disque, en conservant un point de vue externe ?) et va donc dépendre des sondes locales, comme celles fournies par Munin.

Puppet : le directeur de l’établissement

On ne l’a pas encore présenté. Puppet est un logiciel permettant de répliquer de la configuration sur un ensemble de postes. Puppet permet de définir une certaine granularité dans la configuration : il est possible de créer des “groupes” de configuration, pour donner aux postes gérés la configuration qu’il leur faut, potentiellement différente d’une machine à l’autre (un serveur web et un serveur mail n’ont pas les mêmes besoins).

Le fonctionnement

En résumé

Nagios va collecter des informations externes sur le système et recevoir des alertes de Munin.

Munin (“munin-node”) va collecter des informations plus précises sur le fonctionnement de la machine “à chaud”.

Un “master” Munin va centraliser toutes les informations récoltées par les sondes “munin-nodes” et envoyer les alertes à Nagios.

Puppet va se charger d’uniformiser la configuration sur l’ensemble des machines sur lesquelles Munin (munin-node) est installé (mieux que le copier/coller : on change une fois et c’est toutes les machines qui changent).

Les machines

Les machines que l’on suppose présentes sont :

Les machines à administrer (“nodes”) sur lesquelles on mettra les “munin-nodes” et les “puppet-nodes”.

Le “puppet-master” qui va envoyer aux “nodes” la configuration à appliquer

Le “master” Munin qui va centraliser les informations des sondes, et éventuellement faire des graphes.

Le concentrateur nagios, qui va également effectuer les tests externes sur les machines.

Notez que le Puppet master, le master Munin, et Nagios peuvent être portés par la même machine (puppet master, master munin, nagios).

Dans la partie suivante

Dans la prochaine partie, nous verront comment installer et configurer Nagios et ses sondes. Nous verront ensuite dans les parties suivantes le détail de la configuration de Munin, sa communication avec Nagios, et la réplication de sa configuration avec Puppet.

Lire la partie suivante : Nagios.

Voir l’ensemble des articles de la série.

Git push origin master : erreur 22

Mathieu — Sat, 26 Nov 2011 18:04:00 +0100

Petite note pour eux qui ont comme moi suivi les conseils et les exemples sur Internet pour installer un serveur Git avec WebDAV, il faut savoir que c’est comme avec Subversion, le serveur WebDAV aime pas trop les protocoles loufoques (https, as-t-on idée ?), et qu’il faut lui expliquer gentiment de faire de la substitution de protocole, pour le calmer.

Bref, comme j’ai cherché pendant trois heures, je vous livre la solution à cette erreur 22, il faut expliquer à Apache de remplacer https par http lorsqu’il passe à WebDAV.

RequestHeader edit Destination ^https http early

En principe ça ne change rien sur le fait que la connexion soit chiffrée, ça calme juste le module WebDAV derrière, pour qu’il retrouve ses petits. Autre petite astuce, pour éviter que un client un peu bête ne passe sur le http parce qu’il a pas compris :

SetEnv redirect-carefully 1

Et en exclusivité mondiale, je vous livre ma configuration, au cas où ça vous serait utile :

Pour Subversion :

SetEnv redirect-carefully 1 RequestHeader edit Destination ^https http early <Directory /path/to/repos/> AllowOverride None Options Indexes Order allow,deny Allow from all </Directory> <Location /repos> DAV svn SVNPath /path/to/repos/ SetEnv redirect-carefully 1 AuthType Basic Authname "Subversion repository" AuthUserFile /path/to/passwd AuthzSVNAccessFile /path/to/authz # Repository accessible en lecture sans identification <LimitExcept GET PROPFIND OPTIONS REPORT> Require valid-user </LimitExcept> </Location>

Pour Git :

SetEnv redirect-carefully 1 RequestHeader edit Destination ^https http early Alias /repos /path/to/repos <Directory /path/to/repos> AllowOverride None Options Indexes MultiViews Order allow,deny Allow from all </Directory> <Location /repos> DAV on SetEnv redirect-carefully 1 AuthType Basic Authname "Git repository" AuthUserFile /path/to/repos #Oui, normalement là il faudrait une gestion des groupes pour read/write mais bon... #<LimitExcept GET PROPFIND OPTIONS REPORT> Require valid-user #</LimitExcept> </Location>

VNC inversé et traversée de pare feu

Mathieu — Sat, 10 Jul 2010 11:33:00 +0200

Ce billet décrit en détail comment mettre en place un dispositif de contrôle à distance via le logiciel VNC, fonctionnant en mode inversé (le client est serveur et le serveur est client) en traversant les deux pare feu à la fois autour du client et du serveur, en se servant d'une machine relais.

Définitions

Dans la suite de l'article je vais utiliser le terme « client » pour désigner la machine qui va réaliser le contrôle, et « serveur » pour la machine à administrer. Comme nous fonctionnerons en VNC inversé, ça sera le serveur qui demandera la connexion au client qui écoutera les demandes de connexion.

Prérequis

La machine « cliente », celle qui contrôlera la première, doit être sous Linux, ou un autre système intelligent. Il est aussi possible je pense d'avoir un truc comme cygwin, ou alors un moyen efficace de créer des tubes SSH.
La machine relais doit avoir un accès SSH, avec la bonne configuration de ce dernier pour qu'il autorise les tunnels à ressortir, mais nous y reviendrons.

Problématique

Comment mettre en place un contrôle à distance sachant que :

Les deux machines sont derrière un NAT qui nous empêche d'entrer.
Que nous n'avons pas accès aux NAT pour forwarder des ports.
La prise de contrôle doit être décidée par le client, sans avoir besoin que le serveur intervienne, ou que l'utilisateur lance le serveur.

Nous avons ici un triple problème : le NAT du serveur nous empêche de rentrer, on ne peut pas ouvrir de ports, et le NAT du client nous empêche aussi de rentrer, nous empêchant de créer la connexion « inversée » (où c'est le client qui écoute et le serveur qui connecter).

Heureusement nous avons sous la main un serveur tiers pour faire relais, et la machine cliente implémente la norme POSIX (comprendre : l'OS est un unix et il est intelligent).

Solution

Voici comment on va procéder :

Mettre en place un VNC inversé sur le client, mais qui écoute ... en local.
Créer un tube SSH du port d'écoute local vers le serveur relais.
Expliquer au serveur relais de faire sortir le tube.
Faire se connecter la machine à administrer sur le port ouvert du relais, forwardé par nos soins.

Ce dessin réalisé par mes soins devrait vous aider à y voir plus clair :

Installation du client et du serveur

Le serveur : la machine serveur étant sous windows, on va utiliser UltraVNC, disponible ici : http://www.uvnc.com/download/index.html
Le client : la machine cliente est sous Linux, on va utiliser vnc4viewer, qui est dans les paquets de la plupart des distributions

Vérification de la configuration du relais

Alors là je suis désolé pour ceux qui n'ont pas d'accès root sur le relais, il leur sera impossible de vérifier à moins de créer le tube SSH et de vérifier qu'il ressort (en lui parlant dedans avec netcat par exemples).

Le serveur SSH doit en effet posséder le GatewayPorts activé, pour que les sockets SSH puissent être bindés vers l'extérieur et non pas accessibles seulement en local. Il doit bien y avoir un moyen de crée un second tube pour faire sortir la socket locale pour contourner ce problème, mais ici j'ai fait au plus simple : j'ai rajouté GatewayPorts yes dans la configuration, et relancé le serveur SSH.

Vérifiez donc la présence de la ligne suivante dans votre /etc/ssh/sshd_config :
GatewayPorts yes

Lancement du client et essai du tube

Si tout s'est bien déroulé, vous avez installé vnc4viewer sur le client linux, et vous êtes prêt à le lancer.

Donc, lancez le avec la commande vncviewer -listen

Lançons maintenant le tube, la commande est ésotérique mais je vais essayer de l'expliquer :
ssh -f -R*:5500:localhost:550 monlogin@serveurrelais.com sleep 3600

Le -f indique que nous voulons créer un tube SSH
-R indique le sens du tube, même si les sockets sont bidirectionnelles, il faut indiquer où est l'entrée (qui écoute) et où est la sortie (qui envoie des données en réponse)
Le * signifie qu’on écoute tous les hôtes en sortie, et pas seulement localhost, c’est nécessaire dans notre cas pour que le serveur windows puisse s'y connecter (mais il agit alors comme un client, puisque on est en inversé, c'est pour ça qu'il va se connecter sur l'entrée, vous suivez ?)
localhost indique l'endroit où brancher l'entrée, ici localhost c'est le serveur relais, on s'y connecte et au lieu de rediriger le tube vers un éventuel autre serveur, on crée le tube local 4le trait vert du dessin5 pour router sur la bonne sortie sur la même machine
ensuite 5500 c'est le port de sortie, de l'autre côté, c'est la machine linux avec le client qui écoute (puisque on est en inversé)
La suite indique à quel serveur on va se connecter et avec quel login
Enfin, le sleep 3600 est la commande à faire exécuter par le serveur pour maintenir le tube ouvert ; en effet, le client SSH permet de créer un tube à usage unique, juste pour une commande, comme on veut y faire passer plein de trucs dedans, on va lancer cette commande qui ne fait rien mais qui permet au tube de rester ouvert. La valeur 3600 correspond à 1h.

En résumé, cette commande s'utilise ainsi :

ssh -f -Rportdistant:hoteacontacter:portlocal moi@machinedistante commandealancer dans un sens
ssh -f -Fportlocal:hoteacontacter:portdistant moi@machinedistante commandealancer dans l' autre sens

Lancez la commande précédemment décrite, et essayez le tube. Pour essayer le tube, faites simplement :

netcat serveurrelais.com 5500

Si tout fonctionne, vous devriez voir le client en écoute vous dire qu'il a reçu de la visite :
Sat Jul 3 18:17:12 2010 CConn: Accepted connection from 0.0.0.0::45907

Lancement automatique du serveur vers le client en écoute

J'ai choisit de créer une « Tâche planifée » Windows pour que le serveur sous windows tente de contacter le client à travers le tube.

La commande à lancer est toute simple : "c:\Program Files\UltraVNC\winvnc.exe" -connect ipserveurrelais::5500

Conclusion

Nous avons mit en place un système particulier : le serveur est client, le client est serveur, le serveur contacte le client à intervalles réguliers, et c'est le client qui décide quand le serveur va être contacté. Ce branchement peut servir à mettre en place une backdoor sur l'ordinateur serveur, cependant le changement de résolution et de fond d'écran lors de l'établissement de la connexion avec le client devrait faire tiquer celui qui utilise le serveur à ce moment là.