jbbarth's corner

Sur mon serveur perso, j’ai des besoins simples en terme de mails :
1- envoyer des mails (relai local) n’importe où
2- recevoir des mails sur mes domaines (jbbarth.com et autres)

Seulement voilà, à force de suivre des tutos à droite à gauche, de piquer des conseils d’un côté et de l’autre, et surtout de me référer à la doc officielle Postfix, impossible de s’y retrouver. Je relayais des centaines de spams par jour sans savoir pourquoi, de quoi s’arracher les cheveux.

Premier coupable, Postfix : je ne me suis pas paluché tous les MAN ni toute la doc officielle dans la longueur, mais après en avoir lu une bonne partie, ce truc est d’une complexité e-ffra-yante. OK, c’est puissant, mais après ? En 1 ligne mal placée on fout toute une conf par terre, génial.

Enfin en regardant autour, Exim n’a pas l’air beaucoup plus simple bien qu’il m’attire nettement plus (ça m’a l’air souple, sympa, c’est le choix Debian par défaut, etc.).

Vient le second coupable, moi : j’ai édité les confs à la main, en tatonnant. Là, je décide de rester sous Postfix, mais de chercher une doc bien foutue. Et là hourra, merci Debian encore (<3), je trouve cette page de wiki ; voici donc :

tar cvzf /home/salvor/postfix.tgz /etc/aliases* /etc/postfix/
wajig remove —purge postfix
wajig install postfix
sudo -s
tail /var/log/mail.log
postconf -e "myorigin = chanmasters.com"
postconf -e "myhostname=$(hostname)"
postconf -e "relay_domains = chanmasters.com, vds171.sivit.org, jbbarth.com, trollsports-trial.com"
postfix reload
vi /etc/postfix/main.cf
#ajout des restrictions proposées sur le debian wiki
vi /etc/aliases
#on vérifie que les aliases sont toujours en place
#au besoin, un petit coup de "newaliases"
postconf -e "alias_maps = hash:/etc/aliases"
postfix reload
echo "test" | mail -s "1. Mail test to root" root
echo "test" | mail -s "2. Mail test to webmaster@chanmasters.com" webmaster@chanmasters.com
echo "test" | mail -s "3. Mail test to jeanbaptiste.barth@gmail.com" jeanbaptiste.barth@gmail.com
tail /var/log/mail.log
#les trois mails semblent bien passer
#ils sont bien arrivés où il faut
#mêmes tests de l'extérieur
tail /var/log/mail.log
#idem, ça roule \o/

:-)

EDIT: petit oopsie, j’ai rajouté l’option permit_mynetworks à la liste smtpd_recipient_restrictions (en premier), et pour des raisons pratiques (liées au comportement par défaut de Rails), j’ai désactivé le TLS pour le moment. Et là, ça marche !

Récemment nous avons rencontré divers problèmes au boulot concernant la supervision du CPU : remontées à 100% alors que “top” indiquait 0%, parfois des remontées en “UNKNOWN” sans raison évidente, etc.

Modes de supervision de la charge CPU

J’écourte l’intro faite sur le wiki du boulot : on peut en gros compter sur 2 sources d’information pour superviser le CPU d’une machine Linux/Unix :

• des commandes système : top (top -b -n 1 + grep/head/sed), vmstat, voire si vous avez de la chance procinfo ou autres.
• via SNMP, qui propose deux types de compteurs : les compteurs moyennés (ssCpu*) et bruts (ssCpuRaw*). Pour des raisons pratiques, on va se concentrer sur ce mode.

Il y a aussi la charge CPU calculée directement par le système, bien sûr. Mais son calcul comme son interprétation sont complexes, varient en fonction du nombre de processeurs, et, accessoirement, la définition varie d’un Unix-like à un autre. Cela dit si ça vous intéresse, il existe plusieurs plugins (peut-être ça aussi, indirectement).

Je viens de trouver ce plugin qui m’a bien pu, et qui gère apparemment le multi-processeur. Mais ça gâche la suite de l’article alors… revenons donc à la terre ferme.

A. Les compteurs ssCpu

Référence: http://net-snmp.sourceforge.net/docs/mibs/ucdavis.html#ssCpuIdle

Le démon snmpd fournit en standard des compteurs ssCpuIdle, ssCpuUser, etc., directement exprimés en pourcentages, qui devraient permettre de superviser l’occupation du CPU sur une période récente. D’ailleurs on ne sait pas exactement laquelle, je n’ai pas trouvé de référence à ce sujet. Mais ces compteurs sont dépréciés, considérés comme non fiables, et inutilisables en l’état sur une plateforme multi-processeurs ou multi-coeurs (le total arrive, selon les implémentations, à 100% ou N*100%). Le script check_snmp_load.pl, utilisé avec l’option “netsc”, utilise un de ces compteurs, le ssCpuIdle. Ce script est fourni en standard avec le bundle Nagios3 que j’ai au boulot.

Mais il semble notamment que ce compteur n’est pas fiable au-delà de 62 jours d’uptime sur les RHEL5 (tickets sur le bugtracker RedHat ici et ici). Ce genre de bêtise, ça donne quand même envie de se flinguer, merci RedHat…

B. Compteurs ssCpuRaw

Référence: http://net-snmp.sourceforge.net/docs/mibs/ucdavis.html#ssCpuRawIdle

Les compteurs ssCpuRaw* fonctionnent sur un mode différent :

$ snmpwalk -v 2c -c public myserver.domain.tld 1.3.6.1.4.1.2021.11 |grep CpuRaw
UCD-SNMP-MIB::ssCpuRawUser.0 = Counter32: 7184735
UCD-SNMP-MIB::ssCpuRawNice.0 = Counter32: 3142
UCD-SNMP-MIB::ssCpuRawSystem.0 = Counter32: 7208896
UCD-SNMP-MIB::ssCpuRawIdle.0 = Counter32: 1116976279
UCD-SNMP-MIB::ssCpuRawWait.0 = Counter32: 4329138
UCD-SNMP-MIB::ssCpuRawKernel.0 = Counter32: 6038492
UCD-SNMP-MIB::ssCpuRawInterrupt.0 = Counter32: 53534
UCD-SNMP-MIB::ssCpuRawSoftIRQ.0 = Counter32: 1116870

Il s’agit de compteurs permettant de jauger l’utilisation du Cpu depuis l’initialisation du compteur. Pour connaitre l’utilisation du Cpu sur une période récente, il faut donc prendre les valeurs à un instant t, prendre les valeurs à un instant t+1, et faire la soustraction. C’est ce que faisait notre script au boulot, “check_net-snmp_cpu_usage.pl”, récupéré d’une instance Nagios1.3/Oreon.

Seulement ce script fait les choses “bêtement”, il prévoit une intervalle fixe entre les deux checks pour faire la différence. Or ces compteurs ne sont pas mis à jour en temps réel, mais à intervalles plus ou moins réguliers, en général 2 secondes, mais ça peut monter à 10 ou 15 secondes en cas de forte charge du serveur (à la louche). Résultat, soit on règle l’attente à 15 secondes et dans la majorité des cas on attendra 15 secondes inutilement, soit on règle ça a des valeurs moindres, et de temps en temps le script sortira en UNKNOWN.

Comment faire ? premier essai : check_cpu_load.rb

Voir mon espace Github

Ce script fait la même chose que check_net-snmp_cpu_usage.pl mais de façon un peu plus intelligente : il récupère une première série de valeurs. Puis chaque seconde il en récupère une nouvelle, et il attend que le nombre de cycles CPU total écoulé entre sa mesure en cours et la première série soit suffisamment important. Ensuite (ou au bout de 15 secondes par sécurité), il fait le calcul et sort. Si les compteurs sont mis à jour rapidement et que le delta est représentatif, il peut sortir la mesure au bout d’1 ou 2 secondes. Sinon, il attend d’avoir une mesure plus représentative, au cas où le serveur travaille peu (peu de cycles CPU), ou si les compteurs ne sont pas mis à jour (serveur saturé).

Deuxième essai : check_cpu_avg.rb

Voir mon espace Github

Mais cette mesure n’est pas très pertinente : vérifier toutes les 5 minutes ce que fait le CPU d’une machine sur les 3,4,5 dernières secondes n’est pas représentatif. Il suffit de lancer la commande à la main plusieurs fois de suite pour s’en convaincre, admirez les écarts en quelques secondes sur mon serveur de supervision :

CPU Used OK: 10.17% | Wait=1.52%, System=0.99%, User=6.67%, Nice=0.00%, Idle=89.83%
CPU Used OK: 23.66% | Wait=2.49%, System=1.77%, User=17.63%, Nice=0.00%, Idle=76.34%
CPU Used OK: 11.39% | Wait=1.84%, System=1.12%, User=7.31%, Nice=0.00%, Idle=88.61%
CPU Used OK: 42.97% | Wait=1.59%, System=3.43%, User=34.52%, Nice=0.00%, Idle=57.03%
CPU Used CRITICAL: 99.01% > 90 | Wait=1.64%, System=13.64%, User=70.09%, Nice=0.00%, Idle=0.99%
CPU Used CRITICAL: 92.06% > 90 | Wait=1.02%, System=4.76%, User=16.44%, Nice=65.08%, Idle=7.94%
CPU Used CRITICAL: 100.00% > 90 | Wait=0.00%, System=3.41%, User=6.31%, Nice=86.86%, Idle=0.00%
CPU Used OK: 41.59% | Wait=4.00%, System=3.16%, User=8.58%, Nice=22.70%, Idle=58.41%
CPU Used OK: 30.33% | Wait=19.17%, System=1.51%, User=8.14%, Nice=0.00%, Idle=69.67%
CPU Used CRITICAL: 94.22% > 90 | Wait=0.35%, System=11.70%, User=70.46%, Nice=0.00%, Idle=5.78%

=> ça ne varie pas toujours autant certes, mais lorsque c’est le cas, ça bouge autant que dans un top, ce qui n’est pas le but recherché. A la limite on se moque (?) des pics de charge instantanés. L’objectif est plutôt de détecter si une machine reste à 100% de CPU trop longtemps, auquel cas une application a peut-être un problème, ou la machine est peut-être sous-dimensionnée.

L’idée consiste à ne faire qu’un “passage” de la commande SNMP, de stocker les résultats dans un fichier, et de regarder le delta au check Nagios suivant. C’est ce que fait check_cpu_avg.rb. Il sort en UNKNOWN s’il ne trouve pas de fichier stockant un check précédent, et sinon, il fait la différence (qui devient donc une moyenne sur la période entre les deux checks, 5 minutes environ pour nous), stocke les nouvelles valeurs dans le fichier et renvoie le résultat de la différence.

Peut-être qu’il est plus pertinent de superviser à la fois ce genre d’indicateur et le LOAD au sens Linux. Il faudrait en creuser la définition du load précédemment cité). C’est un peu obscur pour moi pour le moment, mais si un lecteur a un avis, défoulez-vous !

En super-vrac même :

• je me suis enfin sorti du Rhume A, la variante non-mortelle de la Grippe A
• en ce moment je deviens un gros adepte de Chrome/Chromium ; Chrome est le navigateur web made in Google. C’est tellement rapide que j’étais presque sur le point de désinstaller Firefox de mon netbook. Vivement que Firefox 3.6 sorte (et surtout que les plugins soient mis à jour), ou que Chromium voit arriver tous mes plugins préférés.
• UNIX a 40 ans cet été ! (via)
• je vais bientôt pouvoir comprendre mes chats grâce à ce merveilleux bijou technologique
• j’étais un peu mort de rire en lisant cet article de Tristan Nitot : S’attaquer aux tabous pour devenir écolo. Où l’on souligne en particulier qu’utiliser des ampoules basse conso, c’est bien moins efficace que limiter le nombre d’enfants (la croissance de la population mondiale étant suicidaire à long terme)
• un joli fake qui donne envie de faire plouf (dans 2 jours !!)
• des robots qui jouent, des robots qui courent, et encore des jolis robots. On est a un tournant, même si c’est encore certainement très compliqué à produire et à rentabiliser, la robotique devient extrêmement performante, Asimov n’est pas loin !
• une chouette initiative pour trouver des équivalents libres aux logiciels propriétaires ; mais le problème reste entier, il n’y a toujours pas (à mon sens) d’équivalent sérieux à .. Visio par exemple.
• ahah, merci la liste railsfrance, qui m’a fait découvrir ce site à envoyer aux imbéciles qui polluent les forums/groupes sans même chercher eux-mêmes auparavant
• Korben nous montre la première voiture volante grand public, wOw !!
• ruby-istes, web developpers, allez voir ça :)))
• quelques liens, à froid, sur les déboires du jeune rappeur énervé Orelsan : poum, poum, et poum. Et un autre pour la route, plouf : j’ai envie de pleurer quand je vois ce qu’on fait de la liberté d’expression en France, j’éprouve une haine féroce contre tous ces penseurs indulgents qui victimisent les gens et les dispensent de penser (ça me rappelle mes cours de philo sur la religion…). On devrait être libre de tout dire, punto.
• les choses à dire pendant l’amour chez Maïa, ahahah
• toujours chez Maïa, les vieux me gonflent < pareillement, quand on lit ce genre de stupidité on espère que l’euthanasie se généralise rapidement :)
• CSS progresse, et html 5 aussi ; vous ne profiterez de ce dernier lien qu’avec Firefox 3.5 minimum, ça n’impressionnera que les développeurs web, mais wouhouh quand mêm :)

Bon, ayé, ma liste ReadItLater est enfin vide (tu parles Charles, j’ai passé au moins 50 liens sur mon compte Delicious…), je peux partir en vacances ! Ahem.