Skip to content

Linux Attitude

Le libre est un état d'esprit

Archive

Archive for August, 2009

Niveau :      
Résumé :accton ; ac ; sa ; lastcomm

Le noyau linux fournit une fonctionnalité ancienne, mais parfois bien utile nommée process accounting. Pour ceux qui compilent leur noyau elle est disponible dans les options générales sous le nom "BSD process accounting".

Pour pouvoir en profiter sur votre système, il faut aussi disposer des commandes disponibles dans le paquet acct. Ces commandes sont peu nombreuses. La première est accton qui active ou désactive l'accounting sur le système. La plupart des distributions incluent un fichier dans init.d appelant cette commande au démarrage.

Une fois l'accounting activé, les données liées aux processus sont stockées dans /var/log/account/pacct (ou équivalent). Les autres commandes du paquets servent à lire ces données.

Les plus importantes sont sa et lastcomm. Notons tout de même ac qui donne le temps de connexion total des utilisateurs et last (en provenance d'un autre paquet) indiquant les dates de connexion des utilisateurs. Un système non GNU vous proposerait des commandes supplémentaires.

sa permet d'obtenir des statistiques sur le lancement des processus.

lastcomm permet d'obtenir une liste de commandes lancées par utilisateur.

Usage

lastcomm permet de surveiller l'activité utilisateur sur le système. On peut ainsi retrouver qui a fait quoi en cas de problème (si vous pouvez garantir le fichier de log bien sûr :-). Un BOFH peut même s'amuser à espionner en temps réel ses utilisateurs avec un watch -d.


continue reading...

Niveau :      
Résumé :lo ; 127.0.0.1

L'interface de loopback se retrouve sur toutes les machines ou presque. pensez à l'activer si ce n'est pas fait par défaut car un certain nombre d'applications en dépendent et son absence peut parfois mener à des bugs inexplicables (à ce propos évitez de mettre un firewall bloquant 127.0.0.1 ...). Mais comment fonctionne-t-elle ?

Localhost

Tout d'abord l'adresse de loopback (127.0.0.1) permet par convention de contacter la machine locale sans passer par une interface qui serait accessible de l'extérieur. Cette fonctionnalité est en soit disponible sur n'importe quelle interface réseau. Il faut juste ajouter une entrée de firewall pour éviter l'accès depuis l'extérieur. Exemple pour prouver que c'est une ip comme une autre :

# on enlève le range d'ip de l'interface lo
$ ip addr del 127.0.0.1/8 dev lo
# on l'ajoute à une interface physique
$ ip addr add 127.0.0.1/8 dev eth0
# on teste
$ ping 127.0.0.1

En pratique, rien n'empêche cette ip d'être accessible publiquement si ce n'est que ce n'est pas recommandé et que linux ne répondra pas (je n'ai pas vraiment cherché à savoir pourquoi).

Device lo

Lo est l'interface de loopback. Celle sur laquelle on met habituellement l'adresse de localhost. Mais cela n'empêche de mettre d'autres ip sur cette interface. Dans un contexte de routeur c'est même très fréquent. Le routeur dispose d'un ip publique qui n'est sur aucune de ses interfaces.

Exemple :

$ ip addr add 172.16.20.1 dev lo
$ ping 172.16.20.1

Le but n'est pas de contacter localhost, mais de contacter le routeur depuis n'importe où, à travers n'importe quelle interface, cette ip est indépendante de l'état des différentes cartes réseaux.

Exemple dans lequel m1 serait un routeur ayant une interface 10.0.0.1 connectée à m2 directement sur le même réseau :

# Première machine
m1$ ip addr add 172.16.20.1 dev lo
m1$ echo 1 > /proc/sys/net/ipv4/ip_forward

# Deuxième machine, on contacte le loopback de m1
m2$ ip route add 172.16.20.1 via 10.0.0.1
m2$ ping 172.16.20.1

L'interface de m1 agit comme un routeur pour son ip de loopback.

Un autre usage particulier de cette adresse est d'autoriser plusieurs machines à disposer de la même ip, sans les annoncer sur le réseau (puisqu'elles ne sont sur aucune interface publique). On peut ainsi éviter les conflits (arp ...). C'est par exemple la solution retenue pour faire de la répartition de charge avec keepalived entre plusieurs serveurs ayant la même ip publique.

Niveau :      
Résumé : pam_unix sha512

Il y a quelques années, le format de stockage des mots de passe unix a changé, permettant de passer du trop simple DES à un algorithme de votre choix. Au passage le stockage s'est fait dans /etc/shadow pour limiter encore plus l'accès à la version chiffrée de ces mots de passe.

Traditionnellement on utilise un hashage MD5 des mots de passe, ce qui se reconnaît par un $1$ au début des mots de passe dans le fichier shadow.

Mais il se peut que vous n'ayez plus confiance en MD5, dans ce cas, rien ne vous empêche d'utiliser un autre algorithme. C'est très simple; il suffit de modifier /etc/pam.d/common-password ou l'équivalent de votre distribution avec la ligne suivante :

password   sufficient  pam_unix.so min=4 sha256

Et changez votre mot de passe, vous verrez alors le préfixe devenir $5$ dans le fichier shadow. Les valeurs possibles sont les suivantes :

  • md5 : $1$
  • sha265 : $5$
  • sha512 : $6$
  • blowfish : $2a$ (déclaré comme fonctionnel seulement sur certaines distributions)

Si la valeur n'est pas comprise par pam_unix c'est la valeur par défaut (MD5) qui sera utilisée.

Sinon tant que vous êtes là à regarder bêtement votre configuration pam, profitez-en pour mettre en place pam_cracklib.

Niveau :      
Résumé : syslog-ng

Syslog-ng est un système de log qui est maintenant installé par défaut sur un certain nombre de distributions. Mais on l'utilise rarement au mieux de ses capacités.

Syslog-ng permet de faire un filtrage des logs, de centraliser un système de logs et d'avoir une configuration simple et plus souple.

Configuration de base

Le fichier de configuration de syslog-ng est très structuré. On y définit deux choses : des options et des logs.

Les options sont globales au système de log et les logs sont un ensemble de règles s'appliquant à une entrée de logs. Ces règles sont elles-mêmes définies par : des sources, des filtres, des destinations et éventuellement des flags.

Voila, je vous ai décrit la structure d'un fichier de configuration. Passons rapidement sur les éléments les plus importants, les logs.

Une entrée log se définit assez aisément comme suit :

source -> filtre -> destination

Syslog-ng sait lire un bon nombre de sources dont :

  • un pipe unix
  • un fichier spécial tel que /proc/kmsg sous linux
  • un pipe
  • un port tcp ou udp

Un filtre permet de ne garder qu'une partie des logs qu'on donne à syslog pour stockage. Syslog-ng sait filtrer en fonction de qui ou quoi a envoyé le message :

  • en fonction du niveau de gravité
  • en fonction de la "facility"
  • en fonction d'expression régulières ...

continue reading...

Un peu de lecture pour vous faire patienter avant un prochain article plus intéressant.

Ça y est, c'est le grand jour !

Le moteur du site a changé et au passage son apparence. Pour info j'utilise maintenant wordpress.
Il y a encore quelques petites choses à mettre à jour et quelques petits bugs. Il est possible qu'un certain nombre de flux, par catégorie notamment, ne fonctionne plus. Je vais tenter de les remettre.

Répondez au nouveau sondage visible à droite, et si vous rencontrez un quelconque problème, n'hésitez pas à me le signaler en commentaire.

Non je ne suis pas mort. Imaginez simplement que j'étais en vacances.

Je suis en train de refaire le site et de changer de moteur. Cela implique un certain nombre de tests pour garder les fonctionnalités. Mais cela me permettra de m'amuser avec plein de nouveaux plugins, et surtout je pourrai choisir un thème convenable.

Par contre cela veut dire qu'il est possible qu'un certain nombre de choses ne marchent plus. Je fais tout mon possible pour conserver toutes les url, mais je ne pourrai peut-être pas garder les flux de commentaires tous fonctionnels, il y aura des redirect, mais il semble que certains lecteurs de flux ne les supportent pas.

Cela veut aussi dire que dès que le site est refait, c'est reparti pour de nouveaux articles, que j'espère toujours aussi passionnants, et toujours plus nombreux.