PROJET AUTOBLOG


Nicolargo

source: Nicolargo

⇐ retour index

Mise à jour

Mise à jour de la base de données, veuillez patienter...

L’écosystème autour de Glances

lundi 26 août 2013 à 10:35

Le nombre de projets gravitant autour de Glances étant devenu assez important, j'ai dessiné le schéma suivant (à partir du service en ligne Gliffy pour les plus curieux d'entre vous):

L'écosystème Glances

L'écosystème Glances

Le cœur de Glances (source disponible sur le Github officiel) est représenté en vert.

On trouve ensuite en bleu les projets composant son écosystème:

CheckGlances

MetaGlances

 

Android Glances

 

Cet article L’écosystème autour de Glances est apparu en premier sur Le blog de NicoLargo.

Présentation des nouveautés de Glances 1.7

samedi 10 août 2013 à 16:26

De retour de congés avec dans ma besace une nouvelle version de Glances qui sera la dernière version majeure de la série 1.x. La prochaine version sera donc une 2.x avec notamment un gros travail initial de refactoring/découpage du code en modules car le script initial atteint une taille critique (plus de 4400 lignes) qui commence à le rendre difficilement évolutif.

Mais revenons donc à nos moutons pour parler de cette version de Glances 1.7:

screenshot Glances 1.7

Un peu d'histoire

Pour ceux d'entre vous qui découvrent Glances dans ce billet, c'est un projet que j'ai lancé maintenant il y a 2 ans pour palier à un manque dans les outils de supervision système. En effet, j'utilisais tout un tas de logiciels (netstat, top, ntop, ifstat, dstat...) pour investiguer les éventuels problèmes de performance sur un système d'exploitation. Mais aucun ne permettait une visualisation simple (via un terminal par une connexion SSH) et rapide (sur un seul écran) des statistiques nécessaires. Glances était née.

Cette version apporte, en plus de son lot de corrections de bugs, d'améliorations des performances et de la documentation de nouvelles fonctionnalité que nous allons détailler ensemble

Les "Monitored Processes List"

L'objectif qui se cache derrière cette nouvelle fonction est de pouvoir, en un clin d'oeil, voir l'état d'un ensemble de processus regroupés ensemble sous une même thématique.

Par exemple, sur un machine hébergeant un serveur Web dynamique, la supervision des processus "importants" peut se découper de la manière suivante:

On a donc 5 objets à superviser. Dans Glances, la définition de ces objets est faite via le fichier de configuration glances.conf. Chaque objet est défini par:

et optionnellement par:

Note: par défaut, Glances par sur le principe ou le groupe ne contient qu'un seul processus (donc countmin = countmax = 1)

Ainsi, la configuration de l'objet n°1 (on peut définir jusqu'à 10 objets) correspondant au serveur Web Nginx est donc la suivante:

[monitor]
list_1_description=Serveur Web Nginx
list_1_regex=.*nginx.*
list_1_command=nginx -v
list_1_countmin=1
list_1_countmax=4

Dans Glances, l'affichage des objets se fait de la manière suivante:

monitored

La couleur détermine l'état de l'objet. Si le nombre de processus:

Comme pour toutes les autres statistiques importantes de Glances, le changement des états est logué.

En mode client/serveur la liste des items est défini au niveau serveur. Une nouvelle entrée dans l'API permet au client de récupérer la liste sur le serveur.

Supervision de la température des disques

Sur certain système, notamment les NAS, la température des disques est un critére important à surveiller. En partant de ce postulat, MendelGusmao a développé un module optionnel (activable en passant l'option -y au lancement de Glances) permettant d'aller récupérer la température des disques sur le daemon HDDTemp qui doit être lancé sur votre machine (voir ici les instructions d'installation de HDDTemp sur Debian/Ubuntu).

Sur ma machine (qui ne comporte qu'un seul disque dur), j'obtiens l'affichage suivant:

hddtemp

Il est bien sûr possible de définir les seuils d'alertes dans la section [hddtemperature] du fichier de configuration de Glances. Les valeurs par défaut sont: CAREFUL=45 / WARNING = 52 / CRITICAL = 60 (en ° celcus).

Information sur l'état de charge de la batterie

J'ai reçu plusieurs demandes d'utilisateur de Glances souhaitant superviser la capacité de la batterie (notamment dans le cas d'utilisation de nano PC autonomes). Premier problème, PsUtil ne remonte pas ce genre de statistiques (du moins dans la version actuelle 1.0). Après une rapide et non exhaustive recherche sur le net d'une bibliothéque Python permettant d'obtenir simplement les informations disponibles sur les systèmes Linux j'ai du me résoudre à coder moi même quelque chose. C'est donc ainsi que Batinfo est apparu il y a quelques semaines.

L'intégration de la librairie Batinfo a été ensuite une formalité et Glances propose donc, si une ou plusieurs batteries sont détectés, l'affichage du pourcentage de capacité restante au milieu du footer:

battery

Limitation: cette statistique est uniquement disponible sur les systèmes Linux.

Une option pour un Glances "low CPU"

Le traitement de la liste comprenant les processus est un des facteur principaux de la consommation CPU de Glances. Sur certain système (notamment les nanos PC comme les Raspberry Pi), il est conseillé de réduire le taux de rafraichissement des statistiques pour faire baisser cette consommation CPU. Cependant, si vous avez besoin d'un taux de rafraichissement important sans avoir besoin du détail des processus alors l'option -r codé par J.Renner est faite pour vous. En lançant Glances avec l'option -r, vous allez désactiver tout les traitements des processus (liste dynamique, monitored process list...) et ainsi disposer d'un Glances faiblement consommateur de CPU.

Sur ma machine de développement, l'utilisation de cette option fait passer la consommation CPU de 2.9% à 0.3%.

Détail de la CPU au lancement de Glances

Une version précédante de Glances voyait apparaître une option (activable en appuyant sur la touche '1' dans Glances) permettatn d'afficher le détail de la CPU par coeur et non plus globalement. Une nouvelle option sur la ligne de commande (-1) permet de lancer par défaut ce mode d'affichage.

per-cpu

IPv6

Enfin un vrai support IPv6 pour le mode client serveur de Glances.

A tester simplement et localement avec:

glances -s -B ::0

pour lancer le serveur en mode IPv6 avec un bind sur toutes les interfaces.

Puis ensuite on lance le client sur le localhost IPv6:

glances -c ::1

Et puis...

Quelques autre petites nouveautés:

Conclusion

Tout d'abord un grand merci aux principaux contributeurs de cette nouvelle version:

Ensuite, je compte sur vous pour tester cette nouvelle version qui est dès à présent disponible sous Pypi (les packages Debian, BSD, Windows et Mac ne devrait pas trop tarder).

Installation et mise à jour de Glances 1.7

Si vous avez installé Glances via Pypi (ce que je conseille), une mise à jour peut se faire simplement via la ligne de commande:

sudo pip install --upgrade Glances

Pour une installation toute fraîche (pour les nouveaux venus ayant les droits root):

sudo pip install Glances

ou la commande équivalente pour une installation locale (pour les nouveaux venus sans les droits root):

pip install --user Glances

Si vous préférerez utiliser les packages Debian/Ubuntu, Windows et Mac OS, il va falloir attendre un peu que mes "packagers" attitrés bossent un peu.

J'attend vos retours sur les commentaires suivants ou vos retour de bug/demande d'amélioration sur le site du dépôt officiel.

Cet article Présentation des nouveautés de Glances 1.7 est apparu en premier sur Le blog de NicoLargo.

Support de présentation SophiaConf 2013 – Raspberry Pi

dimanche 7 juillet 2013 à 19:20

Pas trop le temps de bloguer en ce moment entre le boulot, le développement de la prochaine version de Glances et... la préparation de la conf de présentation du Raspberry Pi que j'ai faite jeudi dernier dans le cadre des SophiaConf 2013.

Voici donc le support de présentation que j'ai utilisé et qui est bien sûr ré-utilisable comme tout ce que je publie sur ce site (licence CC BY 3.0).

Elle est disponible à partir de ce lien ou en cliquant sur l'image ci-dessous (j'ai utilisé le framework de présentation Shower).

Raspberry - SophiaCOnf 2013

Pour avoir une version PDF, il suffit d'ouvrir la présentation dans votre navigateur Web et de faire imprimer vers PDF !

Cet article Support de présentation SophiaConf 2013 – Raspberry Pi est apparu en premier sur Le blog de NicoLargo.

BatInfo, une lib Python pour vos batteries

lundi 24 juin 2013 à 11:30

Je souhaitais ajouter dans Glances un plugin permettant de superviser l'état des batteries. J'ai donc commencé à chercher une librairie Python permettant de s'acquiter le plus simplement possible de cette tache qui sous un système GNU/Linux consiste à analyser le répertoire /sys/class/power_supply maintenu à jour par le noyau Linux.

Comme je n'ai pas trouvé mon bonheur, j'ai donc décidé de développer un librairie Python: BatInfo.

Les sources de cette librairie sont disponibles sur Github en licence LGPL.

Installation

L'installation sur votre système peut se faire simplement via la librairie Pypi:

sudo pip install batinfo

L'utilisation de la librairie dans vos développement Python est la suivante, on commence par inclure la librairie:

import batinfo

Puis on créé une instance (bat) de la classe principale (batteries):

bat = batinfo.batteries()

On peut récupérer les données brutes (format JSON) en utilisant:

bat.stat
[{"status": "Full", "capacity": 50, "name": "CMB1", "uevent": "POWER_SUPPLY_NAME=CMB1\nPOWER_SUPPLY_STATUS=Full\nPOWER_SUPPLY_PRESENT=1\nPOWER_SUPPLY_TECHNOLOGY=Li-ion\nPOWER_SUPPLY_CYCLE_COUNT=0\nPOWER_SUPPLY_VOLTAGE_MIN_DESIGN=10800000\nPOWER_SUPPLY_VOLTAGE_NOW=12496000\nPOWER_SUPPLY_CURRENT_NOW=0\nPOWER_SUPPLY_CHARGE_FULL_DESIGN=5800000\nPOWER_SUPPLY_CHARGE_FULL=5800000\nPOWER_SUPPLY_CHARGE_NOW=3900000\nPOWER_SUPPLY_CAPACITY=100\nPOWER_SUPPLY_MODEL_NAME=CP293550-01\nPOWER_SUPPLY_MANUFACTURER=Fujitsu\nPOWER_SUPPLY_SERIAL_NUMBER=01A-Z100320001158Z", "alarm": 0, "charge_full": 5800000, "voltage_now": 12496000, "serial_number": "01A-Z100320001158Z", "cycle_count": 0, "current_now": 0, "charge_now": 3900000, "voltage_min_design": 10800000, "path": "/sys/class/power_supply/CMB1", "technology": "Li-ion", "manufacturer": "Fujitsu", "type": "Battery", "model_name": "CP293550-01", "present": 1, "charge_full_design":5800000}]

Les données brutes se présentent sous la forme d'une liste de dictionnaire (un dictionnaire par batterie présente sur votre système). Comme la plupart du temps les machines (portable) ont une seule batterie, on peut avoir le dictionnaire associé à cette première batterie avec:

bat.stat[0]
{"status": "Full", "capacity": 100, "name": "CMB1", "uevent": "POWER_SUPPLY_NAME=CMB1\nPOWER_SUPPLY_STATUS=Full\nPOWER_SUPPLY_PRESENT=1\nPOWER_SUPPLY_TECHNOLOGY=Li-ion\nPOWER_SUPPLY_CYCLE_COUNT=0\nPOWER_SUPPLY_VOLTAGE_MIN_DESIGN=10800000\nPOWER_SUPPLY_VOLTAGE_NOW=12496000\nPOWER_SUPPLY_CURRENT_NOW=0\nPOWER_SUPPLY_CHARGE_FULL_DESIGN=5800000\nPOWER_SUPPLY_CHARGE_FULL=5800000\nPOWER_SUPPLY_CHARGE_NOW=3900000\nPOWER_SUPPLY_CAPACITY=100\nPOWER_SUPPLY_MODEL_NAME=CP293550-01\nPOWER_SUPPLY_MANUFACTURER=Fujitsu\nPOWER_SUPPLY_SERIAL_NUMBER=01A-Z100320001158Z", "alarm": 0, "charge_full": 5800000, "voltage_now": 12496000, "serial_number": "01A-Z100320001158Z", "cycle_count": 0, "current_now": 0, "charge_now": 3900000, "voltage_min_design": 10800000, "path": "/sys/class/power_supply/CMB1", "technology": "Li-ion", "manufacturer": "Fujitsu", "type": "Battery", "model_name": "CP293550-01", "present": 1, "charge_full_design":5800000}

Les statistiques présentes dans le dictionnaire dépende de votre batterie. Mais on retrouve un certain nombre d'informations génériques comme par exemple la capacité restante (en %):

bat.stat[0].capacity
50

la capacité maximale:

bat.stat[0].charge_full
5800000

ou encore la capacité courante:

bat.stat[0].charge_now
3900000

On peut aussi avoir des informations constructeurs:

bat.stat[0].manufacturer
'Fujitsu'
bat.stat[0].technology
'Li-ion'

En espérant que cette librairie soit utile à certains. Si vous avez des remarques/rapports de bug à faire, merci d'utiliser le Github: https://github.com/nicolargo/batinfo/issues

Il ne me reste plus, pour ma part, qu'à intégrer cela dans Glances.

Cet article BatInfo, une lib Python pour vos batteries est apparu en premier sur Le blog de NicoLargo.

Ma méthode pour gérer les règles IpTables

lundi 10 juin 2013 à 09:58

iptables"Ooopsss..."

Cette phrase a été prononcée au moins une fois par toute personne ayant administré les règles de Firewall d'un serveur. Les conséquences vont du simple blocage d'une application critique (dont on s’aperçoit de l'indisponibilité au prochain "check" sur son serveur de monitoring) à la perte de connexion pure et simple vers la machine (même pour corriger sa boulette).

Pour éviter de se retrouver dans cette situation et ainsi éviter les rires et moqueries des collègues, voici quelques pistes que j'utilise pour administrer mes règles IpTables sur mes serveurs Debian.

1. Regrouper la sécurité dans un script de démarrage

Il y a plusieurs écoles pour gérer les règles de Firewall. Celle proposée par le wiki officiel de Debian repose sur l'utilisation exclusive des commandes iptables-save et iptables-restore qui permettent respectivement de sauvegarder et de restaurer une configuration IpTables existante.

Pour ma part, je préfère inclure ces commandes dans un script de plus haut niveau que je positionne dans le répertoire /etc/init.d et qui sera donc lancé au démarrage du serveur. Ce fichier firewall.sh est disponible sur mon GitHub DebianPostInstall ou via Gist.

En voici une version à ce jour:

Par défait le script met en place les règles suivantes:

L'utilisation de ce script est standard, ainsi pour appliquer les règles de Firewall:

sudo service firewall.sh start

Pour supprimer les règles de Firewall (attention votre serveur sera ainsi exposé aux attaques extérieures puisqu'aucunes restriction d'accès ne sera appliquée):

sudo service firewall.sh clear

Attention: Il est également possible d'utiliser cette commande avec l'option stop (sudo service firewall.sh stop), mais il faut être conscient que toutes les connexions, entrantes et sortantes seront alors interdites (même votre SSH !!!). Cette commandes est donc à éviter bannir si l'on utilise une connexion à distance pour administrer son serveur...

2. Modifier les règles

On entre ici dans le vif du sujet de ce billet: Comment procéder quand on doit modifier les règles de sécurité ?

La première chose à faire est d'être sûr d'avoir les connaissances nécessaires avant de toucher à quoi que ce soit. Cela peut sembler évident, mais faire des copier/coller de règles trouver sur le net et que l'on ne maîtrisent pas est, sans aucun doute, le meilleur moyen de tout faire planter. Pour modifier les tables IpTables, il faut donc avoir un verni de connaissance général sur le protocole TCP/IP (notamment les notions d'adresses et de port sources/destinations). On trouve pour cela quelques très bon cours en ligne comme celui de chez Developpez.com ou bien la bible de Tanenbaum: Réseaux 5em édition aux éditions Pearson. Bien évidemment, il faut également connaitre les rudiments de la commande IpTables en lisant la documentation officielle (disponible en Français) et notamment la section sur le filtrage de paquets.

On peut passer aux choses sérieuses en identifiant les règles courantes grâce à la commande:

sudo iptables -n -L -v --line-numbers

On obtiendra alors une sortie dépendante des règles actives (exemple pour un de mes serveurs):

Chain INPUT (policy DROP 13 packets, 1398 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1     381M  138G fail2ban-ALL  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0
2     495K   83M fail2ban-SSH  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:22
3     251M   23G fail2ban-HTTP  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:80
4     380M  138G fail2ban-ALL  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0
5     606M  241G ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
6    64473 3711K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:22
7      12M  653M ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:80
8        1    44 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:1337
9    55724 3343K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:4949
10      85  4064 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:5001
11   53603 3216K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:61209
12      13   532 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:123
13    224K   21M ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:161
14       0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:5001
15       0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:22
16    230K   22M ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0
17   4822K  289M ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
18   3684K  435M LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 4
19       0     0 ACCEPT     tcp  --  *      *       88.190.254.200       0.0.0.0/0           tcp spt:20
Chain FORWARD (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
Chain OUTPUT (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1      98M  183G ACCEPT     all  --  *      lo      0.0.0.0/0            0.0.0.0/0
2     253M  912G ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
3        1    84 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0
4        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            195.20.242.89       tcp dpt:80
5        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            212.211.132.32      tcp dpt:80
6        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            212.211.132.250     tcp dpt:80
7      179 10740 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:21
8      276 14700 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:22
9     1254 75180 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:25
10   91789 5507K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:80
11   12940  776K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:443
12    688K   46M ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpts:1024:65534
13     90M 5705M ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:53
14   30171 2293K ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:123
15       0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            88.190.254.200      tcp dpt:21
16      78  3120 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 4
17      78  3120 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable
Chain fail2ban-ALL (2 references)
num   pkts bytes target     prot opt in     out     source               destination
1     761M  277G RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0
2        0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0
Chain fail2ban-HTTP (1 references)
num   pkts bytes target     prot opt in     out     source               destination
1     251M   23G RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0
Chain fail2ban-SSH (1 references)
num   pkts bytes target     prot opt in     out     source               destination
1       10  1568 DROP       all  --  *      *       61.155.150.217       0.0.0.0/0
2     408K   77M RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0

Une fois que vous avez identifié la règle IpTables à ajouter dans votre configuration,  il est maintenant temps de passer à l'action.

Ne jamais, jamais, modifier directement la table avec une commande IpTables sur un serveur en production...

Plusieurs solutions sont possibles, personnellement, j'utilise la méthodologie suivantes:

  1. je commence par copier le script firewall.sh dans un autre répertoire (par exemple dans /tmp/firewall.sh)
  2. j'ajoute la règle IpTables dans la copie du script (/tmp/firewall.sh)
  3. je teste les nouvelles règles en utilisant l'option "test" du script ainsi modifié qui va sauvegarder les règles actuelles, appliquer les nouvelles, attendre 30 secondes puis ré-appliquer les règles actuelles (donc au pire au fait une boulette de 30 secondes...)
  4. si tout se passe comme attendu pendant les 30 secondes, alors je copie le fichier /tmp/firewall.sh sous /etc/init.d
  5. et j'applique les règles en production le moment voulu

Les lignes de commandes correspondantes sont:

sudo cp /etc/init.d/firewall.sh /tmp/
sudo vim /tmp/firewall.sh
sudo sh /tmp/firewall.sh test
sudo cp /tmp/firewall.sh /etc/init.d/
sudo service firewall.sh restart

Ainsi, en cas de problème dans les règles, le serveur ne sera indisponible que pendant 30 secondes. Dans le cas "pas de bol" ou le serveur crache durant ces 30 secondes alors les anciennes règles seront rechargées au redémarrage.

Pas de script ?

Si vous ne souhaitez pas mettre en place un tel script de démarrage des règles de Firewall, il est quand même possible (même si je ne le conseille pas pour avoir une vue d'ensemble des règles à appliquer) de reproduire la méthodologie d'écrite dans le chapitre précédant.

Ainsi, il est tout à fait possible d'utiliser une commande du type:

sudo iptables-save > /etc/iptables.backup && sudo iptables <nouvelle regle a appliquer> && sleep 30 && sudo iptables-restore < /etc/iptables.backup

Conclusion

Comment gérez-vous vos règles de Firewall sur vos serveurs GNU/Linux ? Des astuces à partager avec nous dans les commentaires ?

Cet article Ma méthode pour gérer les règles IpTables est apparu en premier sur Le blog de NicoLargo.