Fedora-Fr - Communauté francophone Fedora - Linux

Planet de Fedora-Fr : la communauté francophone autour de la distribution Linux Fedora

A propos

Cette page est actualisée toutes les heures.

Cette page est une sélection de blogs autour de Fedora. Fedora-Fr.org décline toute responsabilité au sujet des propos tenus par les auteurs des blogs de ce planet. Leurs propos sont leur entière responsabilité.

Le contenu de ce planet appartient à leurs auteurs respectifs. Merci de consulter leur blogs pour obtenir les licences respectives.

Mot-clefs : Administration

Utilisation de rkhunter

Edouard Bourguignon Il y a des outils assez simple à utiliser et qui permettent de s'assurer de l'intégrité de son système. Dans la recherche de rootkit et autres backdoors, l'outil incontournable est rkhunter. Nous allons d'abord rappeller ce qu'est un rootkit, puis voir, à la fin de ce billet comment installer et utiliser rkhunter.

Changer le port par défaut de SSH

Edouard Bourguignon Bien sûr il s’agit que d’une ruse, mais elle coûte tellement peu chère à mettre en place, et est tellement

Changer le port par défaut de SSH

Edouard Bourguignon

Pour sécuriser l'accès à son serveur rien de mieux que de déplacer le port d'écoute du démon SSH sur un autre port. Ainsi tous les robots et autres scripts kiddies se heurteront à un mur au lieu de l'habituel réponse du service SSH, car bien entendu toutes ces tentatives d'attaques sont automatisées et configurées pour tenter que le port 22 pour les attaques SSH. Ces attaques n'ont pas le temps de tester d'autres ports, et continueront leur chemin sur l'adresse IP suivante.

Bien sûr il s'agit que d'une ruse, mais elle coûte tellement peu chère à mettre en place, et est tellement efficace que ce serait dommage de s'en priver.

La configuration du port d'écoute se fait dans le fichier /etc/ssh/sshd_config avec la clef Port, par défaut sur 22 et commentée. Il suffit donc de décommenter et de remplacer le port 22 par celui de son choix.

#Port 22
Port 22222

Vous êtes libre de mettre le port que vous souhaitez (faudra juste pas l'oublier) mais autant mettre un port assez élevé.

Derniers points avant de relancer le service SSH  :

  • Autoriser ce nouveau port dans le parefeu
  • Autoriser ce port pour SSH au niveau de SELinux

Pour autoriser le port 22222 au niveau du parefeu (ici firewalld) :

firewall-cmd --add-port=22222/tcp
firewall-cmd --add-port=22222/tcp --permanent

Voilà pour le parefeu. Pour SELinux :

semanage port -a -t ssh_port_t -p tcp 22222

Voila !

Pour vérifier la  liste des ports pour SSH dans SELinux :

semanage port -l | grep ssh

Pour relancer SSHd pour prise en compte de ce changement de port :

systemctl restart sshd

Ce qui est bon à savoir c'est que vous pouvez avoir plusieurs ports d'écoute pour SSH, et même préciser l'ip + port. On peut donc imaginer laisser le port 22 sur un réseau privé, mais changer celui sur le réseau public.

Depuis un client pour se connecter il y a l'option -p pour le client SSH :

ssh -p 22222 toto@mon.serveur.fr

En bonus, le mieux est d'ajouter un bloc de configuration dans votre .ssh/config concernant ce serveur et son nouveau port :

Host serveur
HostName mon.serveur.fr
User toto
Port 22222
Compression yes
ForwardAgent yes
ForwardX11 yes

La prochaine connexion pourra se faire avec simplement :

ssh serveur

Je parlerais sûrement plus tard des autres éléments à installer pour sécuriser son serveur (fail2ban, fwknop etc). En attendant amusez vous bien, et surtout, bonne année 2018 !


Tilix un chouette équivalement à Terminator

Edouard Bourguignon Si vous aimez Terminator, que vous cherchez un bon émulateur de terminal avec les mêmes fonctionnalités, mais sûrement plus léger,

Tilix un chouette équivalement à Terminator

Edouard Bourguignon

Tilix

Si vous aimez Terminator, que vous cherchez un bon émulateur de terminal avec les mêmes fonctionnalités, mais sûrement plus léger, plus réactif, et mieux intégré à Gnome, il y a maintenant Tilix. Il est développé en langage D et GTK3. Il s'intègre donc parfaitement à Gnome.

Tout comme Terminator, il permet de scinder la fenêtre dans tous les sens, afin d'avoir un maximum de terminaux ouverts.

Pour l'installer sur Fedora :

$ sudo dnf install tilix

Il est aussi disponible sur d'autres distributions bien sûr. Par ex sur Archlinux :

$ sudo yaourt -S tilix-bin

Tout comme Terminator, il permet de diffuser les commandes tapées sur l'ensemble des terminaux, ce qui est bien pratique !

L'ergonomie global de Tilix est plutôt bonne, mais pour la gestion des groupes et la diffusion des commandes, elle est moins bonne que Terminator. A voir à l'usage lequel vous préférez.

Le site officiel du projet : https://gnunn1.github.io/tilix-web/

Métrologie avec Carbon-Graphite - Partie 1 - Les concepts

Edouard Bourguignon

Présentation conceptuelle de la métrologie avec la pile "Carbon-Graphite".

Présentation

La métrologie est une des briques fondamentales de la supervision. Pour superviser au mieux, voir venir les problèmes, ou aider les diagnostics, il est toujours bon de s'appuyer sur un maximum de métriques. Les métriques étant juste des valeurs représentant l'état de santé d'un élément précis (CPU, disques, débits réseaux etc), archivées sur une durée plus ou moins longue.

Il y a les outils ancestraux comme MRTG, RRD qui s'occupent déjà très bien de cette partie, et répondent bien à la nécessité d'avoir le plus de surveillance possible. Mais ils manquent tous de souplesse.

La pile logiciel « carbon-graphite » en permettant le stockage d'un ensemble le plus exhaustif possible de métriques, répond elle aussi très bien à ce besoin. Cependant elle offre bien plus, en permettant aussi l'exploitation de toutes ces métriques, une facilité de mise en oeuvre, et une souplesse d'exploitation très intéressante, idéale pour les environnements assez mouvants comme la virtualisation (ou cloud pour les marketeux). Tout cela avec une approche très KISS que j'adore.

kiss.jpg

Afin de pouvoir répondre à ces exigences, il a fallu définir :

  • un protocole le plus simple et le plus leger possible
  • le même concept pour le stockage des métriques
  • un outil efficace de manipulation des données (graphes, fonctions mathématiques, etc)

C'est ce que tente d'apporter l'ensemble « carbon-graphite ».

Le protocole d'envoi des métriques (carbon)

Le démon carbon qui collecte les métriques écoute par défaut sur le port 2003, en UDP. Mais il est possible de passer par TCP si besoin. Mais ça, c'est pas très important.

Le plus important c'est que le protocole pour remonter les métriques à carbon est des plus simples (Yeah KISS !). Il s'agit d'un protocole ASCII PLAIN TEXT, et ça, ça change tout ! Il est donc facilement lisible et utilisable (via netcat par ex, curl ou autres). La "trame" doit juste suivre ce formalisme :

nom.de.votre.metrique valeur [date]

Exemple plus parlant (le CPU 0 de mon serveur 01 est idle à 99%):

serveur01.cpu.0.idle 99

La date si elle est omise sera celle de la réception de la métrique. Sinon il suffit de la préciser au format timestamp unix. Facile ?

Ainsi il est très envisageable de développer une sonde en 1 ligne de shell :

echo "serveur01.cpu.0.idle 99" | nc -u serveur-carbon 2003

C'est tout. Vous venez au passage de coder votre première sonde pour Carbon ! Est-il techniquement possible de faire plus simple ??

Le stockage des métriques (whisper)

Il faut ensuite pouvoir facilement stocker ces métriques (KISS once again !). Sans avoir non plus de configuration ou autres gestes à faire pour ajouter de nouvelles métriques. C'est là aussi toute la souplesse de cette solution. Il est possible d'y voir une sorte de "métrologie à la demande".

Attention, si vous trouvez que j'utilise trop souvent le mot métrique, c'est normal, je suis payé à chacune de ses occurrences... (ahah si seulement...)

La partie "backend" qui s'occupe de stocker les métriques sur disque s'appelle "whisper".

Pour se faire, la métrique est passée à whisper qui va la découper de manière hiérarchique. C'est plus simple que ça en a l'air, en gros il va remplacer les "." par des "/" et voilà! Ainsi nous retrouverons le nom de notre métrique dans larborescence des fichiers générés par whisper et qui stockent nos données.

Imaginons que le répertoire racine de notre base whisper soit /var/lib/carbon/whisper, notre métrique de notre exemple précédent sera stockée dans /var/lib/carbon/whisper/server01/cpu/0/idle.wsp. Pour l'exploitation vu que l'arborescence des fichiers représente la structure de nos données, c'est simple à manipuler.

Ensuite concrètement, dans ce fichier wsp, il s'agit d'une structure de type Round Robin. Pour des raisons de performance, la structure complète du fichier est crée à la première réception de la métrique. La taille est donc fixe. La structure est très rigide et imposée, pour des questions de performances. De toute façon, les données sont toujours du même type (un nom, une valeur, une date). Si vous avez un besoin particulier de stocker autres choses en plus (tags etc), il faudra se pencher sur InfluxDB (entres autres).

A fonction du nombre de métriques que vous recevrez à l'instant T, il faut que votre disque puisse encaisser (en débit et en IO/s). Sinon les métriques ne pouvant être écrites à temps seront stockées en cache par carbon, et au bout d'un moment ça finira par déborder. Et c'est pas jolie.

Chaque métrique, peut se voir associer une granularité et une rétention. Il faudra donc commencer par se poser la question "Qu'est-ce que je souhaite stocker?" mais surtout "avec quelle précision, et sur quelle durée". Ces questions permettront aussi d'estimer la volumétrie nécessaire. (et non 42 n'est pas une réponse)

Finesse des mesures et période de rétention

Toujours en suivant notre exemple, imaginons que nous souhaitons garder les métriques récentes de manière assez précise, puis plus on s'éloignera dans le temps, moins nous aurons besoin de cette finesse. En général c'est assez vrai, il est rare d'avoir à se pencher sur des métriques très précises 5 ans après un problème etc. Ceci dit, si c'est votre besoin, c'est tout aussi possible.

Cette partie dans le vocabulaire "carbon/graphite" s'appelle la gestion des schémas de stockage.

Pour notre exemple, disons donc, 1 métrique toutes les 10 secondes, sur 1 mois, puis nous passerons à 1 métrique toutes les minutes sur 3 mois, puis 1 métrique toute les 5 minutes sur 1 an (noté 10s:1m,60s:90d:5m:1y dans la configuration whisper). Il est possible de continuer longtemps comme ça. Ce mécanisme de rétention est configuré dans /etc/carbon/storage-schemas.conf. Baisser la granularité au fil de temps permet aussi de réduire la taille des bases en faisant des concessions sur la granularité. Ce qui nous amène à une nouvelle question, comment estimer la taille de nos métriques ?

Cette configuration très souple de la granularité s'applique sur des expressions régulières visant le nom de la métrique. Ceci permet de configurer simplement des rétentions et granularités différentes en fonction du nom de la métrique. Encore une fois, cette configuration se fait dans le fichier /etc/carbon/storage-schemas.conf, qui est vérifié toutes les 60 secondes par carbon. Attention l'ordre dans ce fichier est important, la première correspondance trouvée est appliquée.

A chaque changement de granularité, il y a une opération de consolidation (ou agrégation), configurable, que nous verrons plus bas.

Estimation de la taille des métriques

Il faut être honnête, nous nous sommes pas trop griller les neurones jusqu'à présent. J'ai donc voulu pimenter cet article avec un peu de mathématique. Si vous êtes allergique aux maths, l'approche empirique de tester le stockage de métrique pour une machine "témoin", et de multiplier ça par le nombre de machines en cible fonctionne très bien. Mais vous pouvez quand même faire semblant et lire l'explication suivante...

dog_computer.jpg

Pour estimer la volumétrie, il faut savoir qu'un point de métrique pèse 12 octets (c'est loin d'être lourd, pas très heavy metal mais KISS tout de même !). Reprenons notre exemple de rétention (10s:1m,60s:90d:5m:1y) :

  • Pour les métriques à 10s sur 30 jours :
    • Nombre de secondes dans 1 mois : 30 jours * 24 heures * 60 minutes * 60 secondes = 2592000
    • 1 seul métrique par tranche de 10 seconde : 2592000 / 10 = 259200 points
  • Pour les métriques à 60s sur 90 jours :
    • Nombre de minutes dans 90 jours : 90 jours * 24 heures * 60 minutes = 129600 points
  • Pour les métriques à 5 minutes sur 1 an :
    • Nombre de minutes sur 1 an : 365 jours * 24 heures * 60 minutes = 525600
    • 1 métrique par tranche de 5 minutes : 525600 / 5 = 105120 points

Donc au total, 1 métrique vu nos rétentions aura au maximum 259 200 + 129 600 + 105 120 = 493 920 points. La taille approximative du fichier wsp correspondant sera donc de 5 Mo (493 920 * 12 octets). Il faut prévoir une petite entête dans chaque fichier.

Si vous avez 20 serveurs, avec 100 métriques chaques, on arrive vite à de beaux volumes : 20 * 100 * 5 Mo = 10 Gio. En divisant par 2 nos prétentions sur les granularités (10s:1m,60s:90d:5m:1y => 20s:1m,120s:90d,10m:1y), ce qui n'est pas non plus dramatique, nous divisons par 2 la volumétrie nécessaire (donc 5Gio).

Voilà pour une idée sur comment estimer la volumétrie nécessaire. Et comme par défaut les fichiers whisper sont à taille fixe, tant que vous n'ajoutez pas de nouvelles métriques, l'espace utilisé n'évoluera pas.

Agrégation lors d'un changement de granularité

Que fait carbon quand il reçoit une métrique ? Il cherche déjà à savoir quelle granularité lui appliquer, grâce à la configuration faite dans /etc/carbon/storage-schemas.conf. La métrique passe dans la partie whisper pour être enregistrée sur disque, et les différentes finesses vont être calculées.

Quand une métrique bascule d'un niveau de granularité à un autre, il y a consolidation (ou agrégation, aggregation en anglais, je suis bilingue). C'est à dire qu'il faut appliquer une méthode pour changer la granularité. Par défaut, il s'agit de faire une moyenne pour lisser la perte de finesse. Mais ceci est configurable, cette fois dans /etc/carbon/storage-aggregation.conf. Il faut aussi disposer d'assez de valeurs dans la finesse précédente sur les périodes qui se chevauchent. Ceci est configurable via le paramètre xFilesFactor (par défaut à 0.5 ce qui signife qu'il faut 50% des points). 

Ne vous inquiétez pas, les valeurs par défaut couvrent 90% des usages. Ce qu'il faut retenir:

  • A chaque changement de rétention, carbon/whisper fait des calculs (=coût CPU)
  • Pour ces calculs il faut disposer d'assez de points (évitez donc d'avoir des plages de rétentions inutilisées)
  • Pour eviter de drôle de résultats, il vaut mieux que les périodes soit des multiples entre elles (passer d'une métrique toutes les 10s à 1 par minutes c'est ok car on consolide les 6 dernières métriques, mais ko si 1 par 10s puis 1 par 55s, car comment consolider 5,5 dernières métriques??)

La visualisation des données (graphite)

Sans parler de cette partie, nous avons déjà un outils plutôt puissant, et assez simple à mettre en oeuvre et à comprendre. J'ajouterais en plus que le code est en python, donc facile à lire, et très réduit. Mais la pile carbon-graphite ne serait pas complète sans la partie visualisation des données, la partie "graphite" (graphique quoi).

Ce qui est assez intéressant avec le moteur graphite, c'est qu'il fournit en fait un moteur, interrogeable en HTTP, qui peut restituer les données brutes dans plein de formats (json, csv, etc), mais aussi des graphiques (en SVG, JPG etc), tout en ayant une bibliothèque assez large de fonctions mathématiques pour manipuler les données. A noter qu'avant, avec les outils ancestraux, il fallait trop souvent penser dès le début s'il fallait stocker des résultats mathématiques (moyenne, min/max etc). Ici au final, nous avons les métriques brutes, il est du coup possible de les manipuler comme il nous plait après coup. Bien plus simple.

Nous avons donc rien de particulier à faire si nous voulons avoir une moyenne, glissante ou pas, une valeur de percentile, un top 10, des déviants, et même des prédictions de tendance. Facilement utilisable via l'interface web proposée, ou en développant soi-même quelques petits scripts en javascripts (vu que ça cause JSON).
L'interface web proposée est pas si mal, avec peu être un look un peu old-school. Mais elle met facilement à disposition toutes les fonctions possibles et la navigation dans l'ensemble des métriques est simple. Il est même possible de définir des dashboards etc. Mais pour ce type d'usage plus évolué, nous verrons plutôt l'outil Grafana (qui était d'ailleurs à la base que du javascript devant le moteur graphite).

Conclusion

Au final cette solution de métrologie est très satisfaisante, facile à mettre en oeuvre (je ferais sûrement des billets la dessus), et tient la charge à condition d'avoir bien penser son architecture et surtout ses capacités de stockage.
A completer avec une centralisation des logs ELK (que j'ai déjà abordé ici mais c'est vieux) et c'est tout bon.

Ralonger l'historique du shell

Edouard Bourguignon

En shell, l'historique joue un rôle bien pratique en nous permettant de rappeler et/ou de retrouver d'anciennes commandes. Par défaut il ne conserve que 1000 entrées, ce qui suffit bien souvent. Mais sur des serveurs très utilisés, ou pour n'importe quelle autre raison, il est possible de changer cette valeur. Pour cela il suffit d'ajouter dans votre ~/.bashrc la ligne suivante (où de la corriger si elle existe déjà):

export HISTSIZE=3000

Cette valeur sera prise en compte au prochain login, mais pour que ce soit pris en compte immédiatement, au choix:

  • source ~/.bashrc
  • ou taper la commande export HISTSIZE=3000

Pour s'en assurer:

echo $HISTSIZE

Pour voir la taille actuelle de l'historique:

history | wc -l

J'avais déjà cité il y a quelques temps des raccourcis bien pratiques, certains utilisent l'historique.

PS: cette méthode a été testé sous bash uniquement.

Ralonger l'historique du shell

Edouard Bourguignon

En shell, l'historique joue un rôle bien pratique en nous permettant de rappeler et/ou de retrouver d'anciennes commandes. Par défaut il ne conserve que 1000 entrées, ce qui suffit bien souvent. Mais sur des serveurs très utilisés, ou pour n'importe quelle autre raison, il est possible de changer cette valeur. Pour cela il suffit d'ajouter dans votre ~/.bashrc la ligne suivante (où de la corriger si elle existe déjà):

export HISTSIZE=3000

Cette valeur sera prise en compte au prochain login, mais pour que ce soit pris en compte immédiatement, au choix:

  • source ~/.bashrc
  • ou taper la commande export HISTSIZE=3000

Pour s'en assurer:

echo $HISTSIZE

Pour voir la taille actuelle de l'historique:

history | wc -l

J'avais déjà cité il y a quelques temps des raccourcis bien pratiques, certains utilisent l'historique.

PS: cette méthode a été testé sous bash uniquement.

Coloration des logs

Edouard Bourguignon

Un petit utilitaire bien sympa pour colorer vos affichage de log: "ccze". Il s'agit d'un clone de "colorize" mais coder en C, plus rapide et plus leger que son ancètre qui lui était en perl.

Pour l'installer, rien de plus simple:

yum install ccze

Pour s'en servir, c'est pas bien compliqué non plus:

tail -f /var/log/httpd/www.france.fr-acces_log|ccze

Il permet même de sortir ça au format html

ccze -h /var/log/httpd/www.domaine.fr-access_log > /var/www/html/transparence.html

Facile, efficace, et c'est tellement plus jolie avec des couleurs :)

Désactiver le login graphique sous OpenSolaris

Edouard Bourguignon

Un petit pense-bête qui concerne la désactivation du login graphique sous OpenSolaris:

svcadm disable svc:/application/graphical-login/gdm

svcadm étant le gestionnaire de service, un peu l'équivalent de chkconfig sous Fedora/RedHat.

cyrus imap de fedora8 à fedora 10

Edouard Bourguignon

Résolution d'un problème de migration d'un serveur IMAP Cyrus de Fedora 8 à Fedora 10.

Lors d'une migration d'un serveur IMAP sous Cyrus, afin de passer celui-ci d'une Fedora 8 à une Fedora 10, un problème de changement de version dans la version des fichiers plats de type BerkeleyDB est apparu. L'utilisation du collecteur IMAP était impossible vu que Cyrus ne pouvait plus utiliser certains fichiers où il stockait ses informations sur la livraison des courriers. Les logs d'erreurs ressemblent à ceux ci:

Feb 10 11:45:37 facteur lmtpunix[8517]: DBERROR db4: file /var/lib/imap/deliver.db has LSN 1/96296, past end of log at 1/11006
Feb 10 11:45:37 facteur lmtpunix[8517]: DBERROR db4: Commonly caused by moving a database from one database environment
Feb 10 11:45:37 facteur lmtpunix[8517]: DBERROR db4: to another without clearing the database LSNs, or by removing all of
Feb 10 11:45:37 facteur lmtpunix[8517]: DBERROR db4: the log files from a database environment
Feb 10 11:45:37 facteur lmtpunix[8517]: DBERROR db4: /var/lib/imap/deliver.db: unexpected file type or format
Feb 10 11:45:37 facteur lmtpunix[8517]: DBERROR: opening /var/lib/imap/deliver.db: Invalid argument
Feb 10 11:45:37 facteur lmtpunix[8517]: DBERROR: opening /var/lib/imap/deliver.db: cyrusdb error
Feb 10 11:45:37 facteur lmtpunix[8517]: FATAL: lmtpd: unable to init duplicate delivery database

Pour y remédier, il faut mettre à jour le format des fichiers deliver.db et sessions.db avec les commandes suivantes. Mais avant toute chose, il est conseillé de couper le service cyrus-imapd:

[root@facteur] # service cyrus-imapd stop

Pour changer de format les fichiers db:

[root@facteur] # cd /var/lib/imap
[root@facteur] # db_dump deliver.db >deliver.db.dump
[root@facteur] # rm deliver.db
[root@facteur] # db_load -f deliver.db.dump deliver.db
[root@facteur] # db_dump tls_sessions.db >~/tls_sessions.db.dump
[root@facteur] # rm tls_sessions.db
[root@facteur] # db_load -f ~/tls_sessions.db.dump tls_sessions.db

On relance ensuite le service:

[root@facteur] # service cyrus-imapd start

Et voilà on peut se reconnecter au serveur IMAP avec notre butineur de mail préféré.