Tester les destinataires

Pour vérifier comment Exim envoie un email, on utilise le mode test, c’est la commande exim4 -bt adresse

Pour une boîte aux lettres existante :

arditi-host3:~# exim4 -bt alain@arditi.fr
R: dnslookup for alain@arditi.fr
alain@arditi.fr
  router = dnslookup, transport = remote_smtp
  host aspmx.l.google.com      [173.194.76.26]  MX=5
  host alt1.aspmx.l.google.com [142.251.9.26]   MX=10
  host alt2.aspmx.l.google.com [142.250.150.27] MX=10
  host aspmx2.googlemail.com   [142.250.153.26] MX=20
  host aspmx3.googlemail.com   [142.251.9.27]   MX=20
  host aspmx5.googlemail.com   [142.250.157.26] MX=20
  host aspmx4.googlemail.com   [74.125.200.27]  MX=20
arditi-host3:~#

Dans le cas d’une boîte aux lettres réelle, il n’y a pas trop de surprise. C’est plus intéressant de faire le test sur une boîte aux lettres locale, puisqu’on voit la réécriture de l’adresse et l’envoi :

arditi-host3:~# exim4 -bt root
R: system_aliases for root@arditi-host3.arditi.net
R: dnslookup for alain@arditi.fr
alain@arditi.fr
    <-- root@arditi-host3.arditi.net
  router = dnslookup, transport = remote_smtp
  host aspmx.l.google.com      [108.177.15.27]  MX=5
  host alt2.aspmx.l.google.com [142.250.150.27] MX=10
  host alt1.aspmx.l.google.com [142.250.153.27] MX=10
  host aspmx4.googlemail.com   [74.125.200.26]  MX=20
  host aspmx3.googlemail.com   [142.250.150.26] MX=20
  host aspmx2.googlemail.com   [142.251.9.26]   MX=20
arditi-host3:~#

On voit la reécriture de root, utilisateur local en alain@arditi.fr conformément à ce qu’on a déclaré dans le fichier /etc/aliases. On voit également que Exim4 récupère le champ Gecos dans /etc/passwd pour donner le nom root@arditi-host3.arditi.net à l’utilisateur root.

Tester les émetteurs

Pour vérifier quel est le signataire d’un email, il faut utiliser la commande « exim4 -brw adresse » qui affiche le détail de la réécriture des adresses. Pour une boîte aux lettres existante, il n’y a pas de surprises :

arditi-host3:~# exim4 -brw alain@arditi.fr
  sender: alain@arditi.fr
    from: alain@arditi.fr
      to: alain@arditi.fr
      cc: alain@arditi.fr
     bcc: alain@arditi.fr
reply-to: alain@arditi.fr
env-from: alain@arditi.fr
  env-to: alain@arditi.fr
arditi-host3:~#

Pour une boîte aux lettres locale, on voit la transformation :

arditi-host3:~# exim4 -brw root
  sender: alain@arditi.fr
    from: alain@arditi.fr
      to: root@arditi-host3.arditi.net
      cc: root@arditi-host3.arditi.net
     bcc: root@arditi-host3.arditi.net
reply-to: alain@arditi.fr
env-from: alain@arditi.fr
  env-to: root@arditi-host3.arditi.net
arditi-host3:~#

Là aussi, on voit qu’Exim utilise le contenu des fichiers /etc/aliases, /etc/email-addresses et /etc/passwd pour compléter les informations liées au compte root

L’article Tester Exim 1/2 est apparu en premier sur Alain ARDITI's blog.

Le serveur SMTP est souvent la dernière roue du carrosse sur les serveurs de l’Internet. Aussi, il arrive souvent qu’au login sur le serveur, on voit passer un message signalant qu’on a reçu des emails. Beaucoup d’utilisateurs ignorent le message qui est souvent la marque d’un serveur SMTP non configuré.

aa2@apollo:~ $ ssh arditi-host3.arditi.net
Linux arditi-host3 4.19.0-24-amd64 #1 SMP Debian 4.19.282-1 (2023-04-29) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Fri Feb 23 10:43:40 2024 from 68.201.202.129
You have new mail
arditi-host3:~#

Si on décide de regarder ce qu’il y a dans la boîte aux lettres, on a souvent une surprise de ce type :

arditi-host3:~# mail
Mail version 8.1.2 01/15/2001.  Type ? for help.
"/var/mail/root": 1812 messages 1812 new
>N  1 root@localhost     Fri Feb 23 10:43   19/657   Cron <root@localhost> [ -x /usr/sbin/filetraq ] && /usr/sbin/filetraq
 N  2 root@localhost     Fri Feb 23 10:45   19/657   Cron <root@localhost> [ -x /usr/sbin/filetraq ] && /usr/sbin/filetraq
 N  3 root@localhost     Fri Feb 23 10:53   19/593   Cron <root@localhost> [ -x /usr/sbin/filetraq ] && /usr/sbin/filetraq
 N  4 root@localhost     Fri Feb 23 10:54   19/593   Cron <root@localhost> [ -x /usr/sbin/filetraq ] && /usr/sbin/filetraq
 N  5 root@localhost     Fri Feb 23 10:55   18/642   *** SECURITY information for localhost ***
 N  6 root@localhost     Fri Feb 23 10:55   18/675   *** SECURITY information for localhost ***
&

On voit que le serveur émet des alertes, qui, tant qu’on n’a pas ouvert la boîte aux lettres, sont ignorées. D’autre part, le fichier qui contient tous ces emails « /var/mail/root » ne fait que grossir….

C’est dommage, car les messages des crons permettent souvent de diagnostiquer un problème rapidement.

Exim est particulièrement simple à configurer pour faire le minimum, c’est à dire permettre l’envoi des emails administratifs. Pour les emails applicatifs, il est souvent préférable d’avoir un service externalisé d’envoi d’emails pour éviter d’avoir à gérer tous les problèmes de rejets d’emails et de whitelisting auprès des grands acteurs du mail, comme Gmail, Hotmail, Free, Orange, La Poste, etc…

Préliminaires

L’outil dpkg-reconfigure permet d’initialiser la configuration d’Exim de manière interactive en quelques écrans.

Avant de lancer la configuration, il faut s’assurer que la machine a un nom FQDN correct, c’est à dire que la commande « hostname -f » renvoie le nom complet de la machine. Lors de l’installation le nom fourni se retrouve dans le fichier /etc/hostname. C’est le nom court de la machine. Le nom long provient du fichier /etc/hosts dans lequel on doit retrouver le nom court.

Si /etc/hostname contient arditi-host3, dans /etc/hosts on doit retrouver une ligne avec le nom FQDN suivi du nom court.

127.0.0.1       localhost 
51.159.28.23    arditi-host3.arditi.net arditi-host3

# The following lines are desirable for IPv6 capable hosts 
::1     localhost ip6-localhost ip6-loopback 
ff02::1 ip6-allnodes 
ff02::2 ip6-allrouters

Ici, on déclare l’IP du serveur lui-même, mais on peut aussi utiliser une IP locale : 127.0.1.1 pour déclarer le FQDN. On a un fichier de la forme

127.0.0.1     localhost
127.0.1.1     arditi-host3.arditi.net arditi-host3

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

Et la commande répond :

arditi-host3:~# hostname -f
arditi-host3.arditi.net
arditi-host3:~#

Une fois cette étape réalisée, on peut lancer la configuration d’Exim avec la commande dpkg-reconfigure exim4-config

Dans les écrans qui suivent, on indique qu’on va envoyer et recevoir des emails sur Internet, mais comme on mettre 127.0.0.1 en IP d’écoute, aucun mail ne pourra arriver depuis l’extérieur. On est donc dans une configuration qui ne peut qu’envoyer des emails vers l’Internet. On verra dans un autre article l’utilisation d’un relais (smarthost). Dans le nom du système, on met le nom FQDN de la machine.

Configuration des alias et des adresses

Dernier point pour que les emails administratifs fonctionnent, c’est la configuration des alias. En effet, les emails administratifs sont pour la plupart des emails provenant de tâches planifiées (cron), qui sont adressés à « root » par défaut. On va donc donner à root une véritable adresse email grâce au fichier /etc/aliases, c’est la dernière ligne du fichier :

arditi-host3:~# cat /etc/aliases 
# /etc/aliases
mailer-daemon: postmaster
postmaster: root
nobody: root
hostmaster: root
usenet: root
news: root
webmaster: root
www: root
ftp: root
abuse: root
noc: root
security: root
root: alain@arditi.fr
arditi-host3:~#

Pour signer les emails administratifs, et en particulier s’ils bouncent, il faut une boîte aux lettres réelle pour les émetteurs. Ainsi les bounces vont pouvoir revenir sur une boîte aux lettres plutôt que d’être perdus dans le « goulp » ! On déclare ces emails dans le fichier /etc/email-addresses

arditi-host3:~# cat /etc/email-addresses
# This is /etc/email-addresses. It is part of the exim package
#
# This file contains email addresses to use for outgoing mail. Any local
# part not in here will be qualified by the system domain as normal.
#
# It should contain lines of the form:
#
#user: someone@isp.com
#otheruser: someoneelse@anotherisp.com
root: alain@arditi.fr
www-data: alain@arditi.fr
arditi-host3:~#

A noter que j’ai déclaré une adresse pour www-data, car c’est l’utilisateur qui va envoyer les emails lorsqu’on utilise un serveur Apache pour une application Web.

Pour terminer, afin de donner un nom à l’émetteur, on peut modifier le fichier /etc/password et mettre à jour le champ Gecos de l’utilisateur

arditi-host3:~# cat /etc/passwd
root:x:0:0:root-arditi-host3.arditi.net:/root:/bin/bash
....
www-data:x:33:33:Wordpress Contact:/var/www:/usr/sbin/nologin
....

La ligne root contient le nom long, comme ça on voit d’où vient l’email sans avoir à regarder les en-têtes SMTP.

Un email reçu depuis cette machine sera de la forme :

On voit dans cet exemple, la différence entre le destinataire du message qui est root et l’adresse de l’enveloppe, alain@arditi.fr qui permet à l’email de sortir sur Internet et d’arriver dans la boîte aux lettres.

L’article Configuration Exim est apparu en premier sur Alain ARDITI's blog.

Bref, on est confronté, comme souvent sur Internet, à l’énorme quantité d’informations qu’il faut savoir trier. 
C’est au lecteur de se faire une idée et de construire son savoir.
Et quand on travaille seul, on se pose souvent des questions qui restent sans réponse.

Si on travaille en équipe, ça relève de la technique des fourmis, celui qui a trouvé la bonne manière de faire va diffuser l’information aux collègues. Encore faut-il que ce soit effectivement la bonne manière de faire. J’ai vu de nombreux informaticiens utiliser des options qui ne faisaient pas ce qu’ils pensaient…

L’objectif de ce document est de vous exposer ma manière de faire, c’est-à-dire les commandes de base que j’utilise au quotidien dans mon travail d’administrateur système.
Ce n’est pas la meilleure manière ni la plus complète, c’est la mienne. Elle est probablement différente de celle des autres administrateurs, chacun ayant ses propres trucs.
Je vous livre ma manière d’utiliser la ligne de commande, à vous d’y piocher ce qui vous paraît pertinent.

La manière dont je travaille est le résultat d’un long processus qui a pris des années et des années. J’ai commencé à travailler sous Unix en 1988…. J’ai eu la chance de croiser beaucoup d’autres utilisateurs sous Unix ou Linux, dans mon travail quotidien comme lors d' »install parties » ou des salons.

Chacun a sa propre manière d’utiliser la ligne de commande.
Chacun a son propre jeu d’instructions, certains en utilisent beaucoup, d’autres moins. Enfin, certains qui ne veulent pas s’immerger dans Linux, en utilisent le minimum. 

Ce document s’adresse à des débutants, puisqu’on y retrouve les commandes de base et, dans la très grande majorité, dans une utilisation simple.
Mais si on veut comprendre le sens de ces commandes, ou plutôt pour quelle raison il vaut mieux utiliser une commande sous cette forme plutôt qu’une autre, il vaut mieux avoir déjà une expérience de la ligne de commande. Et c’est le sujet de ce partage : la recherche de sens.

C’est comme l’apprentissage du piano. Si votre professeur vous dit de mettre les doigts comme ça, vous le faîtes parce que vous êtes persuadé qu’il faut faire ainsi. Si vous avez déjà fait des années de piano, vous allez comprendre pour quelle raison il fallait le faire ainsi.

Lorsqu’on apprend l’informatique, on est souvent confronté à une problématique de transmission de savoir. On va vous dire que si vous ne connaissez pas une commande, il faut regarder le « man » ou bien chercher sur Internet. Les cours que j’ai eu l’occasion de donner ou de voir sur la ligne de commande, sont soit minimalistes pour les débutants qui n’ont jamais vu une console, soit un partage de syntaxe spécifiques pour des élèves avancés. Dans ce dernier cas, on arrive souvent à l’énumération des options de la commande, qui pour la plupart sont peu utiles au quotidien. On retombe facilement dans la paraphrase du « man ».
Alors, les bons professeurs, lorsqu’ils paraphrasent le man illustrent souvent leur propos avec des exemples. Sinon, ils diraient à leurs élèves : lisez la doc !
C’est d’ailleurs ce qu’on peut critiquer à l’esprit du RTFM.

Si on illustre toutes les options, on se dit que les élèves auront au moins entendu une fois dans leur vie le contenu de cette documentation et s’en rappelleront au moment opportun. C’est ce qu’on se dit tous, en imaginant qu’en lisant l’exhaustivité de cette documentation on va trouver une option magique qu’on n’avait jamais utilisée jusqu’à présent.

A mon avis, il vaut mieux se concentrer sur les bonnes options à retenir et savoir ce qu’elles font exactement plutôt que de connaître vaguement le sens de toutes les options.
Comme souvent en informatique, il faut supprimer le « vague » ou l' »à peu près » de sa manière de penser.

Certains de mes collègues en arrivant dans l’équipe m’expliquaient qu’ils utilisaient toujours rsync avec les options -trolpg. Soit !
Moi j’utilise les options -av ou -avz, les autres options sont des cas particuliers.

On est dans une situation où pour comprendre la manière de faire, il faut déjà avoir un certain bagage. Et des cours où on explique la manière de faire, je n’en connais pas. C’est très souvent en échangeant avec un autre admin qu’on se dit que sa manière d’utiliser telle commande est plus efficace que la nôtre.
Des fois à la lecture d’un article on se dit quelle « cool feature » cette option ! Et on se l’approprie.

La difficulté comme souvent dans l’apprentissage étant de transmettre le maximum d’informations sans noyer les élèves. Si on dit juste qu’il faut utiliser telle commande de cette manière, on restreint souvent très fortement les fonctionnalités de la commande.

Mais c’est mon parti pris : limiter le nombre de commandes et leurs options.

Ce qui ne veut pas dire qu’avec l’expérience, il ne faudra pas aller creuser les autres options ou les autres commandes. D’ailleurs, je remarque que la très grande majorité des administrateurs ont une connaissance encyclopédique des commandes et de leurs options. Cette connaissance, il faudra l’avoir un jour ou l’autre. Même si on utilise certaines options une fois par an !

Alors, le jeu de commandes que j’utilise au quotidien est relativement simple. C’est un compromis entre l’efficacité des commandes et ma capacité à mémoriser les syntaxes.  

Afin d’avoir une démarche rationnelle, j’ai extrait quelques statistiques de mes historiques de ligne de commande.
Les échantillons que j’ai utilisés pour extraire les commandes les plus utilisées sont les suivants :

Top 10 des commandes de base que j’utilise

Note : j’ai pris uniquement la première commande après le prompt sans tenir compte des commandes qui suivent un pipe.

Quelques commentaires

1. Les commandes ci-dessus sont essentiellement des commandes d’administration système. C’est de la recherche d’information pour la réutiliser ou pour la modifier.
2. la commande sudo provient de mes historiques de postes personnels sur lequel je travaille avec un compte utilisateur. Pour les serveurs, je travaille sous root, il n’y a donc pas de sudo. Sauf pour lancer une commande avec l’environnement spécifique à un utilisateur.
3. Si on l’élimine la commande sudo, la commande man arrive en 10^ème position !
4. Une commande particulièrement utile qui n’apparaît pas dans cette liste est « pwd » (Print Working Directory). Comme l’invite de commande (le prompt) affiche le répertoire courant, inutile d’utiliser pwd !
5. Les deux premières commandes cd et ls reflètent l’exploration de l’arborescence des fichiers. Il faut ajouter la commande pwd qui est implicite car affichée dans le prompt. Le triplet de commandes « cd ls pwd » est l’équivalent des explorateurs de fichiers en mode graphique. On se déplace dans les répertoires en cliquant sur le répertoire qui montre alors les fichiers qui s’y trouvent.
6. rsync arrive en 3^ème position. C’est la commande qui permet de copier un fichier ou une arborescence. Je n’utilise plus ou quasiment plus ni cp, ni scp.
7. history est la commande qui permet d’afficher les commandes qu’on a déjà saisies. C’est l’aide mémoire de la ligne de commande, suivi très souvent de la commande grep afin de rechercher une commande en particulier. L’objectif étant de réutiliser au maximum ce qu’on a déjà fait !
8. la commande grep apparaît ici dans le cas où elle est la première commande de la ligne. Elle correspond à des recherches de chaînes dans des fichiers et non pas derrière un pipe. En fait je l’utilise énormément derrière les pipes suite à un history, mais je n’ai pas comptabilisé ce mode d’utilisation.
9. la commande rm (remove), pour supprimer des fichiers ou des arborescences arrive haut dans le listing. 2000 rsync pour 1000 rm, c’est le signe du nettoyage des fichiers obsolètes. Une partie du travail d’administration système consiste à déplacer ou à recopier des arborescences. Il faut ensuite supprimer les fichiers inutiles, ça relève des bonnes pratiques.

Détail des options de ls

Voici plus en détail l’utilisation que je fais de la commande ls, d’après mes historiques :

Les 2 principales options sont :

• ls -l (long) pour avoir le détail de chaque fichier listé par ordre alphabétique
• ls -ltr (long time reverse) pour avoir le fichier le plus récent en bas du listing. C’est la commande qui permet de connaître les fichiers « chauds », donc ceux qui bougent, dans les logs ou les répertoires de configuration par exemple.

Détail des options de rsync

Voici les options que j’utilise le plus souvent

Le bilan pour les rsync tapés en ligne de commande font que les plus simples sont de la forme
rsync -av source destination
et les plus compliqués sont de la forme
rsync -avz –delete -P source destination
L’option -n (dry-run) permet de lancer la commande pour voir ce qu’elle ferait.
L’option -P permet de « voir » la progression du rsync
L’option -c permet de comparer les fichiers source et destination par un checksum. Par defaut rsync considère qu’un fichier est identique sur la source et la destination si la taille et la date de modification sont identiques. Avec -c on peut contrôler une arborescence suite à une intrusion ou limiter le listing des fichiers modifiés….

Les scripts de synchro utilisent principalement des exclusions et parfois l’option –numeric-ids

En voici deux exemples :

rsync -av $DRY --delete \
--exclude=@eaDir/ \
--exclude=".DS_Store" \
--exclude=".TemporaryItems/" \
$SOURCE $DEST

rsync -avz \
--numeric-ids \
--delete \
--exclude="var/cache/" \
--exclude="var/run/" \
--exclude="tmp/" \
--exclude="dev/" \
--exclude="etc/network/" \
--exclude="run/utmp" \
$SRV:/mnt/disk1/$VM/ /mnt/disk1/$VM/

Le –numeric-ids permet de conserver les id utilisateurs et groupes lors du rsync. C’est utile pour manipuler des VM LXC depuis un host sans perturber les permissions de la VM guest qu’on vient de copier.

L’article Linux efficace ou les 10 commandes à connaître est apparu en premier sur Alain ARDITI's blog.

Pour l’installer, rien de plus simple, il suffit de faire un lien symbolique sur un des « aspects » disponibles pour ce plugin, qu’on obtient par la commande :

aa2:~# munin-run varnish_transfer_rates suggest
memory_usage
request_rate
backend_traffic
transfer_rates
threads
bad
uptime
expunge
objects
hit_rate
aa2:~#

Mais avant de pouvoir lancer cette commande pour connaître les « aspects » de ce plugin, il fallait déjà faire un lien symbolique, donc lire le contenu du plugin ! La on choisit l’aspect « transfer_rates ». Pour installer le plugin qui va fournir les « transfer_rates » de Varnish, il faut faire le lien suivant :

aa2:~# ln -s /usr/share/munin/plugins/varnish_ /etc/munin/plugins/varnish_transfer_rates
aa2:~#

A cette étape, la configuration est prête pour tester le plugin. On lance la commande suivante pour vérifier les valeurs que renvoie le plugin :

aa2:~# munin-run varnish_transfer_rates 
.....
Could not get hold of varnishd, is it running?

no element found at line 1, column 0, byte 0 at /usr/lib/x86_64-linux-gnu/perl5/5.28/XML/Parser.pm line 187.
aa2:~#

Pas de réponse, on attend les ….. puis on obtient une erreur ! Cette erreur provient de varnishstat. Quand on lance varnishstat pourtant tout fonctionne :

aa2:~# varnishstat  -x
<?xml version="1.0"?>
<varnishstat timestamp="2021-03-08T22:33:50">
	<stat>
		<name>MGT.uptime</name>
		<value>520285</value>
		<flag>c</flag>
		<format>d</format>
		<description>Management process uptime</description>
	</stat>
	<stat>
		<name>MGT.child_start</name>
		<value>1</value>
		<flag>c</flag>
		<format>i</format>
		<description>Child process started</description>
	</stat>
...
...
</varnishstat>
aa2:~#

Alors que se passe-t-il ? On essaie avec les options de débug :

aa2:~# munin-run --debug --pidebug varnish_transfer_rates 
# Processing plugin configuration from /etc/munin/plugin-conf.d/README
# Processing plugin configuration from /etc/munin/plugin-conf.d/dhcpd3
# Processing plugin configuration from /etc/munin/plugin-conf.d/munin-node
# Processing plugin configuration from /etc/munin/plugin-conf.d/spamstats
# Processing plugin configuration from /etc/munin/plugin-conf.d/varnish4_
# Processing plugin configuration from /etc/munin/plugin-conf.d/varnish5_
# Processing plugin configuration from /etc/munin/plugin-conf.d/varnish_
# Setting /rgid/ruid/ to /113/65534/
# Setting /egid/euid/ to /113 113/65534/
# Setting up environment
# About to run '/etc/munin/plugins/varnish_transfer_rates'
.....
Could not get hold of varnishd, is it running?

no element found at line 1, column 0, byte 0 at /usr/lib/x86_64-linux-gnu/perl5/5.28/XML/Parser.pm line 187.
aa2:~#

Toujours la même erreur. En y regardant de plus près on s’aperçoit que le plugin est lancé avec l’euid 113 qui est l’id de l’utilisateur munin sur ma machine. Mais comme le process Varnish tourne sous l’utilisateur vcache, le plugin ne peut pas contacter Varnish, d’où l’erreur. La méthode pour corriger ce problème est de lancer le plugin Varnish avec l’utilisateur « vcache ». Pour ceci, on crée un fichier de configuration du plugin qui indique d’utiliser « vcache » :

aa2:~# cat /etc/munin/plugin-conf.d/varnish_ 
[varnish_*]
    user vcache
aa2:~# 
aa2:~# munin-run varnish_transfer_rates 
aa2:~# 
aa2:~# munin-run --debug --pidebug varnish_transfer_rates 
# Processing plugin configuration from /etc/munin/plugin-conf.d/README
# Processing plugin configuration from /etc/munin/plugin-conf.d/dhcpd3
# Processing plugin configuration from /etc/munin/plugin-conf.d/munin-node
# Processing plugin configuration from /etc/munin/plugin-conf.d/spamstats
# Processing plugin configuration from /etc/munin/plugin-conf.d/varnish4_
# Processing plugin configuration from /etc/munin/plugin-conf.d/varnish5_
# Processing plugin configuration from /etc/munin/plugin-conf.d/varnish_
# Setting /rgid/ruid/ to /113/109/
# Setting /egid/euid/ to /113 113/109/
# Setting up environment
# About to run '/etc/munin/plugins/varnish_transfer_rates'
aa2:~#

Le plugin fonctionne, mais ne renvoie rien !!!
On tombe sur le bug : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959812

En cherchant les plugins Varnish pour Munin, on trouve beaucoup de choses. Qui vont de Varnish 2 à Varnish 5. Mais sous Buster, on est en Varnish 6. Tous les plugins Varnish ont la même source, la version de 2009. Mais on ne sait pas exactement avec quelle version de Varnish ils fonctionnent. J’en ai essayé 3 différents, et sans aucun doute, le bon est celui-ci : https://gallery.munin-monitoring.org/plugins/munin-contrib/varnish5_/

Il faut récupérer le source, faire le lien dans le répertoire des plugins et mettre l’utilisateur « vcache » ou « root » dans la configuration. Là, j’ai utilisé le hit_rate comme « aspect » :

aa2:~# ln -s /usr/share/munin/plugins/varnish5_ /etc/munin/plugins/varnish5_hit_rate
aa2:~#
aa2:~# cat /etc/munin/plugin-conf.d/varnish5_ 
[varnish5_*]
    user vcache
aa2:~#
aa2:~# munin-run varnish5_hit_rate 
client_req.value 2955
cache_hitpass.value 0
cache_hitmiss.value 12
cache_hit.value 2228
cache_miss.value 715
aa2:~#

On a bien un résultat cette fois !
Remarque, le client_req est calculé comme la somme des 4 valeurs cache_*. Alors que la commande varnishstat renvoie un client_req de 9585 ! Cette dernière valeur représente toutes les requêtes reçues par Varnish, y compris les « pass ». Donc avec le plugin « varnish5_ » on n’a que les requêtes qui sont sensées être en cache. Ce qui est logique pour un calcul de hit ratio, mais qui ne montre pas la totalité des requêtes reçues.

On retrouve ci-dessus un hit ratio dont la somme des 4 composantes fait 100.

Références :
Munin
Paquet Munin pour Debian Buster

L’article Munin : le plugin Varnish sous Debian Buster est apparu en premier sur Alain ARDITI's blog.

Dans cet article on ne traite que la création de la VM dans l’hyperviseur, taillée une pour une distribution minimale. Il restera ensuite à procéder à l’installation de la distribution Debian qui est traitée dans l’article  Installation d’une VM Debian Buster minimale.

« Debian minimale » veut dire qu’on installe un serveur sans interface graphique avec le minimum de paquets. Ça permet d’avoir une VM Debian de base parfaitement configurée pour votre environnement, qu’on clonera pour installer des services.

D’une manière générale, la tendance est à installer autant de serveur que de services. C’est la même idée que les micro-services sous Docker, mais avec de véritables services. De cette manière on a des services indépendants, on peut modifier les composants système pour chacun des services sans impacter les autres services.

Par exemple, si je fais des applications Web, mon infrastructure se compose d’un serveur NGINX pour le cache et le HTTPS, puis j’ai deux applicatifs Web, un WordPress et un Drupal qui ont chacun une base de données MySQL, un serveur Apache et un serveur Varnish. Je pourrais faire tourner tous les composants sur une seule et même VM. Sauf que quand je vais faire la mise à jour de PHP pour WordPress, j’aurais peut-être un problème sur un composant de mon instance Drupal. Par ailleurs mon serveur MySQL contiendrait les base Drupal et WordPress. Si je dois sauvegarder uniquement le WordPress pour une montée de version par exemple, il faut que je prenne soin d’identifier les éléments de l’applicatif WordPress. Dans le même ordre d’idée, si j’ai tous les composants sur une seule VM, le serveur Apache aura une configuration pour l’applicatif Drupal et WordPress, sous deux arborescences séparées, mais avec des directives qui ne sont pas nécessairement simples à maintenir dans la durée.

Séparer les composants par VM, permet d’isoler les configurations ainsi que les versions des composants systèmes qui peuvent ne pas être au même niveau coté Drupal et WordPress, sans poser aucun souci de fonctionnement. Alors, bien sûr on multiplie les VM. Dans le cas présent on aurait 3 VM. Une VM pour la connexion Web qui contient NGINX, une autre VM pour le WordPress, avec Varnish, Apache, MySQL, et une dernière VM pour le Drupal avec Varnish, Apache et MySQL. Il faut donc faire des mises à jour de sécurité pour les 3 VM, gérer 2 serveurs MySQL distincts, gérer les IP, payer des VM, etc….

Mais si on veut passer à Drupal 9 par exemple, il suffit de copier la VM Drupal pour tester la montée de version sans toucher l’environnement WordPress. Là tout devient plus simple. On peut faire des changements d’architecture de nos 2 services sans impact de l’un sur l’autre. On peut même passer d’une VM Debian à une VM CentOS pour le Drupal uniquement. Remplacer le Drupal par un ezPlatform sans rien toucher au WordPress.

La conclusion est que lorsqu’on procède aux installations de tous les composants d’un coup, il paraît souvent plus simple de tout faire sur une seule VM. Mais dans la durée, on se retrouve souvent bloqué au bout que quelques mois ou années, lorsqu’on n’a plus tous les éléments en mémoire et qu’il faut jongler avec la compatibilité de l’ensemble de ce qu’on avait installé.

Prérequis

La création de la VM nécessite quelques ressources.

Comme on souhaite avoir un serveur minimaliste, les ressources allouées à la VM seront minimale.

• 3 Go de disque, l’installation occupera moins de 2Go, il restera 1Go utile.
• 1Go de mémoire RAM. On peut utiliser moins dans la pratique, mais selon les outils qu’on installera, on peut se retrouver bloqué. Mais dans ce cas, il est facile d’allouer de la mémoire supplémentaire à la VM.
• Il faut une connexion Internet, sans quoi il serait inutile de procéder à l’installation par la « netinst » qui justement utilise l’Internet pour aller chercher les paquets utiles.
• La récupération de l’image ISO Netinst de la distribution Debian Buster qu’on trouve sur le site Debian : https://www.debian.org/CD/netinst/
  Pour Windows, Mac OS X ou Linux, c’est très majoritairement l’image amd64 qu’il faut choisir.

Les prérequis disques et mémoire sont indicatifs. On peut utiliser moins de ressources, mais au moins 2Go de disque, sinon, on ne peut pas finaliser l’installation, surtout si on met à jour le noyau Linux, par exemple.

On peut toujours agrandir le disque une fois la VM créée, si on a besoin d’espace disque. Par contre, tant que l’installation Debian n’est pas finalisée, si le disque ne contient pas suffisamment d’espace, il faudra modifier la VM et refaire l’installation. 

Création de la VM VirtualBox

Lancer VirtualBox et cliquer sur le bouton « New… » ou « Nouvelle… » et saisissez les valeurs des paramètres tels que dans l’écran suivant :

Un fois que vous avez cliqué sur le bouton « Create » vous pouvez spécifier les valeurs du stockage disque, c’est à dire une taille de 3Go, alloué dynamiquement :

Une fois le disque créé la VM est créée !

On peut contrôler les paramètres de la VM sur l’écran suivant :

Il faut maintenant indiquer à la VM de charger le CD netinst qu’on a téléchargé précédemment dans son lecteur de CD.
Aller dans les paramètres de stockage et cliquer sur le petit CD à droite pour indiquer où se trouve l’image

et on se retrouve avec une VM prête pour l’installation avec son CD netinst chargé dans le lecteur !

On va pouvoir démarrer la VM et procéder à l’installation de la distribution Debian Buster !

L’article Création d’une VM Debian Buster minimale sous VirtualBox est apparu en premier sur Alain ARDITI's blog.

On arrive aux dernières étapes.
L’installation du boot loader GRUB qui permettra à la VM de démarrer. Sur les hyperviseurs, il n’y a pas de souci particulier car les disques sont standards et le BIOS également.
La valeur proposée par l’installateur Debian convient parfaitement.

Dans l’écran suivant, on choisit le disque de notre VM qui est /dev/sda

On arrive au dernier écran de l’installateur, qui va déclencher le redémarrage de notre VM.

Lorsque vous êtes arrivés là, hormis un problème de boot lié à Grub sur un serveur physique, vous avez réussi l’installation d’une distribution Debian Buster minimale !

L’opération vous aura pris moins d’une heure (selon la connexion Internet), voire moins de 30 minutes lorsque vous êtes rodés !

Le système repart et l’écran de Grub pour le boot se présente :

Si tout se passe bien, la console va présenter la mire de login Debian

On se logge avec le compte root et le mot de passe ad hoc. On peut vérifier les ressources de notre machine :

Cette distribution minimale pèse moins d’1 Go sur le système avec 1 Go de swap.

Comme on peut le voir, l’utilisation de la RAM est ridicule, c’est pour cette raison, qu’on peut parfaitement tourner avec 500Mo de RAM, voir 256Mo et quelques centaines de Mo de swap.

Si on regarde l’état des paquets :

root@debian-buster:~# apt update
Hit:1 http://debian.proxad.net/debian buster InRelease
Hit:2 http://debian.proxad.net/debian buster-updates InRelease
Hit:3 http://security.debian.org/debian-security buster/updates InRelease
Reading package lists... Done
Building dependency tree       
Reading state information... Done
All packages are up to date.
root@debian-buster:~# apt list --upgradable 
Listing... Done
root@debian-buster:~# 

On remarque que tous les paquets sont à jour !
C’est l’intérêt de la « netinst » par rapport à l’installation par le CD, qui aurait nécessité une mise à jour d’au moins 20% des paquets. D’où des téléchargements bien plus importants au bout du compte, que pour l’installation « netinst » !

A partir de là, il va falloir se connecter à cette VM par le réseau, avec le client SSH plutôt que de travailler avec la console système.

Quelques réglages utiles pour VirtualBox sur Mac OS X

La configuration du clavier « French » au début de l’installation permet d’avoir un clavier Azerty, mais pour PC !

Or, sur Mac, la disposition des touches spéciales sur le clavier n’est pas la même que sur PC. Il faut donc reconfigurer le clavier pour avec un clavier Azerty pour Mac ! C’est ce qui est détaillé dans l’article suivant : Reconfigurer un clavier Mac Azerty sur une VM Linux

Retour à l’étape précédente : Installation d’une distribution Linux Debian Buster minimale 2/3

L’article Installation d’une distribution Linux Debian Buster minimale 3/3 est apparu en premier sur Alain ARDITI's blog.

Pour le partitionnement du disque, la stratégie est assez simple, on utilise les valeurs par défaut, c’est à dire « Guided partitionning ». En effet, il est inutile de découper ou d’optimiser le partitionnement puisque la VM réside sur un fichier de l’ordinateur hôte.

Sur une machine physique, on aurait fait un découpage des partitions, de manière à isoler les partitions système et les partitions de données. Mais avec les technologies RAID des serveurs, là encore, inutile d’optimiser le partitionnement, car les couches matérielles s’occupent de l’optimisation pour nous. Le découpage permet par contre, de limiter les dégâts entre les partitions et d’isoler le système et les données. C’est une des règles d’hygiène de l’administration système.

On n’a pas trop le choix sur notre VM, puisqu’i n’y a qu’un disque. A noter que sur les hyperviseur, on peut ajouter des disques dans les VM. Ca n’a aucun interêt si ce n’est de saucissonner le stockage qui aboutira à un manque de ressources plus rapidement qu’avec un seul disque.

Si on a besoin de stockage, il faut augmenter les partitions. Sur un serveur physique, on utilisera du LVM afin de s’abstraire de la couche matérielle RAID.

La proposition de partitionnement automatique se compose d’une partition pour le système et d’une partition de swap pour la mémoire :

A cette étape, on peut réduire la partition de swap, car il n’est pas très intéressant de mettre 1Go de swap sur une machine qui aura quelques centaines de Mo de RAM et dont on ne veut pas faire grossir l’image disque.
Pour réduire la partition #5, il faut la supprimer et la recréer, avec une taille de 500Mo par exemple, et la déclarer du type « swap ». 

On valide le partitionnement et le formatage du disque dans l’écran suivant de manière volontariste, puisque le choix présélectionné est « No » ! Il faut saisir « Yes » !

Maintenant qu’on a du stockage dans la machine, l’installation des paquets peut commencer !

Comme on n’a pas de CD Debian, hormis l’image « netinst » qui vient d’être installée, on répond « No » à l’étape suivante :

Installation d’une VM Debian : configuration du gestionnaire de paquets

On passe à la configuration du gestionnaire de paquets afin que l’installateur puisse aller chercher les paquets qui restent à installer sur Internet. On va préciser les miroirs Debian, c’est dire fournir les sites qui ont la copie de la distribution et qui sont proches de nous sur l’Internet ! C’est bien l’objet de la « netinst » !

De cette manière, à la fin de l’installation on se retrouve avec une version parfaitement à jour !

On va configurer la source des paquets de manière à ce que les débits soient les meilleurs. On sélectionne France (si on est en France…)

Si vous avez un abonnement Free, il faut choisir debian.proxad.net. Si vous ne savez pas quoi choisir, laissez la valeur par défaut « deb.debian.org »

On passe ensuite par la configuration d’un éventuel proxy pour sortir sur Internet

Avec les paramètres qu’on vient de saisir, l’installateur génère la configuration du gestionnaire de paquet Debian « apt »

On passe l’écran « Popularity Contest », surtout pour des VM de test…

On va installer les composants de base pour utiliser notre serveur, c’est à dire le serveur SSH qui nous permettra de nous connecter à distance et surtout avec un terminal et pas la console fournie par l’hyperviseur. On installe aussi des utilitaires systèmes sans quoi on ne peut pas faire grand’chose.

Par contre, on ne coche rien d’autre, sinon, on se retrouve avec des services qu’on ne voudra pas nécessairement par la suite et surtout pas d’environnement graphique, qui ne tiendrait pas dans notre VM de 3Go.

A ce moment, on récupère déjà, uniquement avec le serveur SSH et les utilitaires système, 140 paquets supplémentaires

L’étape suivante consiste à installer le boot loader (GRUB). Cette étape est détaillée dans la page : Installation d’une distribution Linux Debian Buster minimale 3/3

Retour à l’étape précédente : Installation d’une distribution Linux Debian Buster minimale 1/3

L’article Installation d’une distribution Linux Debian Buster minimale 2/3 est apparu en premier sur Alain ARDITI's blog.

Serveur minimal veut dire qui permet d’utiliser des ressources moindres. Dans notre cas, le serveur ou VM si vous installez cette Debian sur un hyperviseur comme VirtualBox, KVM ou VMWare nécessitera :

• moins de 3Go de disque
• moins de 500Mo de RAM

La création de la VM sur VirtualBox, avant de procéder à l’installation est détaillée dans l’article Installation d’une VM Debian Buster minimale sous Virtualbox

La procédure est identique avec un serveur physique et l’image sur une clé USB ou un CD.

Au boot, sur le support d’installation, la clé USB ou le CD, on choisit « Install »

Dans l’écran suivant, on choisit comme langage d’installation, mais surtout comme langage de la VM « English ». En effet, il est préférable d’installer les serveurs en Anglais, car ainsi, on est plus proche de la source et la recherche d’informations sur Internet est facilité.

On arrive à la sélection des Pays, là, on choisit « other », pour sélectionner Europe/France sur les écrans de configuration de l’affichage de l’heure (timezone).

Pour la locale, ce sera en_US UTF8, car là encore, l’idée est de coller à la source et utiliser un système qui restera interopérable avec les autres systèmes plus tard.

Pour le clavier, on choisit « French » (clavier « azerty »). On pourra par la suite configurer plus finement son clavier, en particulier si vous êtes sur un Mac, le mapping des touches n’est pas tout à fait correct. Le caractère – se trouvant sur la touche 6, comme sur un clavier de PC Linux ou Windows. L’installateur configure le clavier Azerty pour PC et à ce stade, il n’est pas possible de modifier cette configuration.

Pour cette raison, il faut utiliser un jeu de caractère assez simple, ASCII, pour saisir les mots de passe des comptes que vous allez créer dans les écrans suivants. Il faut éviter les caractères spéciaux si vous êtes sur un Mac, sans quoi vous pourriez vous retrouver bloqué au login, à ne plus pouvoir saisir le mot de passe. Il est possible de modifier les mots de passe une fois l’installation terminée.

Ensuite, l’installation des paquets démarre. Avant de retrouver l’écran suivant qui demande un nom pour la machine, il y a pas mal d’étapes qui se font automatiquement quand tout se passe bien, comme la configuration réseau par DHCP, par exemple.
Ici, on considère que tout se passe bien.

Il y aura peut-être d’autres articles pour montrer comment ajouter un driver réseau manquant pendant l’installation. Mais a priori, pour une installation virtualisée sous VMWare, KVM ou VirtualBox, il n’y a jamais de problèmes de drivers (sauf optimisation avec VirtIO).

A l’écran suivant on saisit le nom de la machine, ici « debian-buster »

Puis le domaine dans lequel se trouve le serveur. Quand on ne sait pas on peut saisir local.domain. A priori, sauf installation de production, il faut toujours reconfigurer le domaine par la suite…

Ensuite vient la saisie du mot de passe de root. Il faut absolument mémoriser ce mot de passe, en particulier si vous faites des VM de test et que vous les multipliez. Car souvent, au bout de quelques mois, on revient sur une ancienne VM, et sans le mot de passe tout devient plus compliqué.

Par ailleurs, pour la création d’une VM sur Mac avec KVM, VMWare ou VirtualBox, il faut faire particulièrement attention à ne pas saisir de caractères spéciaux à cette étape, car le clavier n’est pas correctement configuré par l’installateur Debian (contrairement à l’installateur Ubuntu !). Si on a un doute sur la configuration du clavier, il ne faut pas hésiter à cocher « Show password in Clear » afin d’être certain des caractères qu’on a saisi.

On saisit à nouveau le mot de passe

Ensuite, on passe à la création d’un utilisateur « non administrateur » pour le travail courant. La saisie du « Nom Complet » est utilisée comme commentaire du login que vous fournirez dans l’écran d’après.

A la première connexion SSH, si vous n’avez pas modifié la configuration d’origine du serveur SSH, c’est cet utilisateur qu’il faudra utiliser, donc le login que vous saisirez dans l’écran suivant, avec son mot de passe pour vous connecter et configurer la VM par le réseau. Il vaut mieux utiliser un client SSH plutôt que la console de l’hyperviseur qui n’est pas toujours pratique pour le copier/coller.

Dans l’écran suivant, on va saisir le login de l’utilisateur. C’est cette chaîne de caractères qui sera utilisée pour se connecter à la VM

Là on saisit le mot de passe de user1. Là aussi, il faut s’abstenir de saisir des caractères spéciaux si votre clavier n’est pas correctement configuré.

L’étape suivante consiste à configurer le disque dur. Cette étape est détaillée dans la page : Installation d’une distribution Linux Debian Buster minimale 2/3

L’article Installation d’une distribution Linux Debian Buster minimale 1/3 est apparu en premier sur Alain ARDITI's blog.

Il y a une différence sur les touches de fonctions entre un clavier Azerty pour PC et un clavier Azerty pour Mac. Ce qui rend parfois acrobatique la saisie clavier de caractères spéciaux dans une VM Linux à partir d’un hyperviseur Mac, comme VirtualBox ou KVM !

On voit que les caractères – _ ! = @ * ne sont pas à la même position !
Saisir le pipe | sur une VM Linux configurée avec un clavier Azerty PC à partir du clavier Mac est relativement difficile, car la séquence habituelle pour saisir le pipe ⌥+Maj+L ne fonctionne plus !

La solution consiste à  reconfigurer le clavier PC de la VM en clavier Mac !

Reconfigurer un clavier Azerty PC en clavier Mac sur Debian Buster

Si vous utilisez des VM sur Mac, et que ces VM sont des VM Linux, alors vous avez probablement eu des problème avec les caractères spéciaux, comme le pipe |, l’étoile *, le tiret – et j’en passe.

En effet, lors de l’installation de la distribution Debian, lorsqu’on choisit le clavier Azerty, on récupère un clavier Azerty pour PC, qu’on soit sur un PC ou un Mac. Par contre, l’installateur Ubuntu détecte cette différence.

Si vous êtes sur un Mac, il faut donc reconfigurer le clavier sur la VM Debian, avec la commande

root@debian-buster:~# dpkg-reconfigure keyboard-configuration

Peu importe les sélections des deux écrans suivants.
Pour un serveur qui n’est pas en mode graphique, la touche AltGr n’apporte rien, pour Mac en tout cas.
Par exemple, le caractère \ sur PC se fait avec AltGr+8 alors que sur Mac, c’est ⌥+Maj+/ !!!

Pour appliquer les changements, il faut rebooter ou lancer la commande

root@debian-buster:~# setupcon

On peut désormais saisir toutes les commandes avec son clavier Mac.
Pour rappel :
le pipe | s’obtient avec ⌥+Maj+L
le tilde ~ s’obtient avec ⌥+N
le backslash \ s’obtient avec ⌥+Maj+/

Références
Le clavier sur Debian

L’article Configurer un clavier Mac Azerty sur une VM Linux Debian Buster est apparu en premier sur Alain ARDITI's blog.