Skip to content

Linux Attitude

Le libre est un état d'esprit

Archive

Archives pour juin, 2009

Niveau : Star Star Empty Empty Empty
Résumé : perl -0777pe ; ps kstart_time ; stty -echo ; expr ; bc -l ; tar c - | ssh tar x -

Petite pause.

Appliquer une expression régulière en une seule fois sur tout un fichier (comme s'il ne faisait qu'une ligne) :

$ perl -0777pe 's/expression/remplacement/'

Connaitre les processus qui sont lancés "en ce moment", par exemple pendant un script d'installation :

# listes les processus par date de création toutes les 2s
$  watch "ps kstart_time aux |tail"

Éviter d'afficher les mots de passe lorsque vous les demandez à l'utilisateur dans vos scripts shell :

$ stty -echo
$ read password
$ stty echo

Faire un calcul en ligne de commande (installé partout, même sur les vieux unix) :

$ expr 1 + 5

Faire un calcul en ligne de commande, mais en mieux :

# à mettre dans votre bashrc de préférence
$ bcl() { echo "scale=2; $@" | bc -l ; }
$ bcl 1+2

Tar over ssh (rsync quoi) :

$ tar cf - /repertoire | ssh mamachine.net "cd /destination && tar xvf -"

Niveau : Star Star Star Star Empty
Résumé :

Suite de la formidable série :

Et après les comptes ?

Il est aussi possible d'utiliser libnss-ldap pour autre chose que pour les comptes utilisateurs. La bibliothèque NSS étant une bibliothèque générique de résolution de nom, il est possible d'utiliser le ldap pour :

  • les groupes (attention pas de login pour newrp à travers pam de prévu)
  • les noms de machine
  • et d'autres qui ne pas très intéressants pour l'instant ...

Pour cela, rien de plus facile, tout est déjà fait, il suffit de modifier la ligne correspondante dans /etc/nsswitch.conf et de commencer à peupler le LDAP.

Un groupe est définit comme suit :

objectClass: posixGroup
cn: mongroupe
description: goupe a moi
gidNumber: 1000
memberUid: peck
memberUid: amiami

Notez que la description est optionnelle et que les membres sont décrits par uid. Le userPassword est aussi disponible mais n'est pas utilisable actuellement pour les groupes du système.

Exemple de machine (plus besoin de DNS local ;-) :

objectClass: ipHost
cn: mamachine
ipNetworkNumber: 1.2.3.4

S'adapter à l'existant

Il est possible que vous ayez à gérer un serveur ldap existant avec ses comptes et son propre schéma (active directory ?). C'est pourquoi il existe des options de mapping dans la configuration de pam_ldap et nss_ldap.

Ces options sont assez simples, il s'agit de reparcourir votre schéma et pour chaque entrée nécessaire pour le système, expliquer au fichier de configuration quel est le nom de l'attribut ou de la classe que vous utilisez sur le ldap. Ceci est à faire une fois pour nss et une fois pour pam.

Les commandes sont :

  • nss_map_objectclass : changer une classe utilisée par libnss-ldap
  • nss_map_attribute : changer un attribut utilisé par libnss-ldap
  • nss_default_attribute_value : donner une valeur par défaut à un attribut (pratique pour le shell par exemple)
  • pam_login_attribute : change l'attribut servant à matcher le login pendant l'authentification
  • Il n'est pas possible de changer l'attribut utilisé par pam pour le mot de passe (normal c'est le serveur ldap qui gère).

Les classes modifiables (en restant dals le domaine utilisateur/groupe) sont

  • posixAccount : utilisateur ayant un compte unix
  • shadowAccount : utilisateur ayant un système avancé de gestion de mot de passe
  • posixGroup: groupe unix

Les attributs modifiables sont : uidNumber, gidNumber, gecos, homeDirectory, loginShell, shadowLastChange, shadowMin, shadowMax, shadowWarning, shadowInactive, shadowExpire, shadowFlag, memberUid

Plus de détails (et plus de clesses) dans la RFC 2307.

La configuration fournie avec le paquet donne des exemples pour les différents systèmes existants (aix, microsoft ...)

libnss-ldapd

Maintenant vous pourriez avoir d'autres problèmes, comme la performance ou quelques hoquets du réseau qui coupent des connexions. La solution traditionnelle pour cela est d'installer nscd qui fera un cache et vous évitera ces problèmes (et peut en créer d'autres puisque c'est un cache).

Mais il existe une autre solution : libnss-ldapd, notez bien le 'd' final. C'est une version de libnss-ldap réécrite pour parler à un démon qui est le seul à parler avec le serveur ldap. Ça a l'avantage de mutualiser les requêtes dans une seule connexion et donc d'éviter pas mal de problèmes, surtout en cas de forte charge.

Petit inconvénient pour les puristes, ça ouvre une faille potentielle (inconnue à ce jour) pour un utilisateur qui voudrait devenir administrateur via le serveur ldap, puisque ce n'est plus le noyau qui vérifie les droits root d'administration mais le démon.

Le démon se configure dans /etc/nss-ldapd.conf. La syntaxe est la même que pour pam_ldap et libnss-ldap, le contenu ne doit pas changer.

Le démon est du coup assez important, il faut vérifier qu'il est lancé (monitorer toussa ...). Il s'appelle nslcd.

Sécurité et performances

Si vous avez beaucoup d'utilisateurs vous pouvez vouloir restreindre les recherches.
Si vous avez des utilisateurs qui ne doivent pas tous avoir accès au système, vous pouvez vouloir restreindre les recherches.

C'est pourquoi nss et pam fournissent des directives pour réduire la taille des recherche et donc la liste des utilisateurs :

  • base : réduit l'accès à toutes les commandes LDAP à une seule branche
  • scope : indiquer si la recherche doit tester les sous branches ou non
  • nss_base_<map> : permet d'indiquer à ldap de se limiter à une requête pour un type donné de résolution, map peut valoir passwd, shadow ou group (ou hosts, services, networks, protocols, rpc, ethers, netmasks, bootparams, aliases ou netgroup). Exemple : nss_base_passwd ou=users,dc=linux-attitude,dc=fr?sub?uid>1000
  • pam_filter : permet de modifier la partir filtre pour pam (pas besoin de modifier le reste car il n'y a qu'une requête faite par pam). Exemple : pam_filter uid>1000

Niveau : Star Star Star Star Empty
Résumé : libmap-ldap ; passwd ; chsh ; chfn ; adduser

Désolé, j'ai oublié la suite de la série LDAP. On peut faire un peu mieux que la dernière fois.

Changer son mot de passe

Nous n'avons pas activé le changement de mot de passe. Pour cela, c'est assez simple, il suffit de modifier common-password (cela peut être ailleurs pour certaines distributions ...) :

password   sufficient   pam_unix.so nullok obscure min=4 max=8 md5
password   sufficient   pam_ldap.so

Il faut aussi modifier /etc/pam_ldap.conf pour que pam ne modifie pas directement le mot de passe, mais utilise les fonctions de ldap prévues à cet effet. Cela permet qu'il ne soit pas stocké en clair, mais avec la méthode définie dans la configuration de ldap ({SSHA} par défaut).

# A ajouter dans /etc/pam_ldap.conf
pam_password exop

Et voilà vous pouvez tester la commande passwd. Mais vous constaterez qu'il y a quelque chose qui cloche. Si vous lancez la commande en root, l'ancien mot de passe vous est quand même demandé. C'est parce que vous n'avez pas les droits d'administrateur sur le ldap.

Pour remédier à cela, il vous faut un compte ldap qui a le droit de modifier le champ password des autres utilisateurs, par exemple l'administrateur ldap. Puis renseignez ce compte dans pam_ldap.conf :

# /etc/pam_ldap.conf
# Il faudra stocker le mot de passe correspondant en clair dans /etc/pam_ldap.secret
# Ce fichier doit appartenir à root et être en mode 600
rootbinddn cn=admin,dc=linux-attitude,dc=fr

Ça y est vous êtes prêts.

chsh, chfn, adduser

Les utilisateurs ont le droit de changer leur shell ainsi que leurs informations personnelles. Pour cela ils ont les commandes chsh et chfn.

Malheureusement ces commandes manipulent /etc/passwd. Le paquet libpam-ldap fournit des script pour remplacer ces commandes, mais ils sont un peu basiques et nécessitent libnet-ldap-perl (Net::LDAP). Vous pouvez vous baser dessus pour faire les votres si vous pensez que ces fonctionnalités sont indispensables pour vos utilisateurs. On les trouve dans /usr/share/doc/libpam-ldap/examples/ . un certain nombre de paramètres sont codés en dur et peu de vérifications d'erreur sont faites.

Si vous modifiez vos binaires dans /usr/bin sur debian, faites attention la prochaine mise à jour risque de les remplacer. Pour éviter ce problème, il existe la commande dpkg-divert :

# On fait croire aux paquets qu'ils installent /usr/bin/chfn alors qu'ils installent en réalité /usr/bin/chfn.old
$ dpkg-divert --add --rename --divert /usr/bin/chfn.old /usr/bin/chfn
# voila, vous pouvez maintenant remplacer /usr/bin/chfn

Autre problème, adduser ne comprend pas non plus le ldap. Ici le problème est le même mais la solution un peu meilleure. Un paquet ldapscripts est disponible et il contient des commandes comme ldapadduser pour vous faciliter la création d'utilisateurs ldap. Les commandes sont configurées dans /etc/ldapscripts/ .

Tout ceci pourrait s'améliorer dans de prochaines versions, un patch a l'air en cours de développement pour le paquet shadow (qui contient ces outils) qui utiliserait la libnss pour effectuer ces actions. Les commandes fonctionneraient donc directement.

Quelques remarques

Depuis que nous avons des vrais comptes systèmes basés sur le ldap nous sommes contents. Mais quelques petites choses tout de même :

  • Gardez le compte root sur le système, on ne sait jamais, si le ldap tombe, vous seriez bien embêtés
  • Faites attentions aux droits dans le ldap, ils impactent les fonctionnalités des commandes systèmes (droit de lister les autres utilisateurs par exemple)
  • Avec un serveur distant, le ldap devient une forme de NIS
  • Vous pouvez utilisez la réplication ldap pour résister aux crash
  • Vous pouvez toujours garder une mot de passe local au cas où le ldap ne marche pas (pam fait les 2)
  • Vous pouvez vous connecter à un controleur de domaine windows
  • Si vous avez de problèmes les logs d'authentification sont dans /var/log/auth.log
  • Vous pouvez vouloir ne mettre en place que l'authentification via pam et ne pas utiliser libnss. Ce cas correspond à des utilisateurs virtuels (comme pour le ftp) qui n'utiliseront pas alors de vrai compte sur le système.

Niveau : Star Star Star Empty Empty
Résumé : libpam-ldap

Hier nous avons créé un compte sur le ldap. Bien, mais on ne pouvait pas en faire grand chose. Il faut maintenant pouvoir se connecter. Il est théoriquement possible de tout faire avec libnss mais c'est à la fois plus difficile et moins fonctionnel qu'avec pam.

Comme vous le savez l'authentification sous linux se fait avec PAM. Nous allons donc utiliser un module dédié : libpam-ldap (cool le paquet porte le même nom).

LDAP

Cette fois ne nous force à utiliser aucun objectClass, mais comme il sait utiliser les attributs de la classe shadowAccount, on peut utiliser celle-ci pour se simplifier la vie.

Ajoutons le mot de passe à notre utilisateur. On crée le mot de passe LDAP à la main, mais par la suite vous verrez que ce n'est pas indispensable.

$ slappasswd -s test
{SSHA}l5X6sBFomfk3tk02HEMWK4YLep7pqZDk

On ajoute ce mot de passe à l'utilisateur déjà créé :

$ ldapmodify -x -D "cn=admin,dc=linux-attitude,dc=fr" -W
dn: uid=peck,ou=people,dc=linux-attitude,dc=fr
changetype: modify
add: userPassword
userPassword: {SSHA}l5X6sBFomfk3tk02HEMWK4YLep7pqZDk

Un test de connexion avec ldapsearch vous montrera que le mot de passe est bien pris en compte :

$ ldapsearch -x -D "uid=peck,ou=people,dc=linux-attitude,dc=fr" -w test "uid=peck"

PAM

Maintenant il faut expliquer gentiment à PAM d'aller faire son authentification en utilisant LDAP. Pour cela hop, configuration dans /etc/pam.d/common-*. Certaines distributions devront peut-être configurer chaque élément un par un : su, login, ssh ...

# common-auth
# attention, le pam_unix devient sufficient
auth    sufficient    pam_unix.so nullok_secure nodelay
# use_first pass permet de ne demander qu'une fois les mot de passe pour les 2 modules
auth    sufficient    pam_ldap.so use_first_pass 
# common-account
account    required    pam_unix.so
account    sufficient   pam_ldap.so
# common-session
session    required    pam_unix.so
session    optional    pam_ldap.so

Maintenant attaquons-nous au fichier de configuration proprement dit : /etc/pam_ldap.conf. En voici l'essentiel :

# /etc/pam_ldap.conf
base ou=people,dc=linux-attitude,dc=fr
uri ldap://127.0.0.1/
ldap_version 3

Vous remarquerez que pam_ldap.conf et libnss-ldap.conf ne rentrent jamais en conflit. Vous pouvez faire un lien de l'un vers l'autre ou modifier la configuration pour que ce soient les mêmes fichiers. Cela peut vous éviter quelques désagréments.

Test

Maintenant tout marche, même l'authentification. Faites le test :

$ su - peck
Password:
$ id
peck

Youpi, ça marche même en ssh. Bon c'est bien gentil, mais c'est encore un peu léger. La prochaine fois , on voudrait pouvoir faire encore plus.

Niveau : Star Star Star Empty Empty
Résumé : nss-ldap

Il y a plusieurs façon de gérer ses comptes par ldap. Commençons par la plus simple. Plaçons-nous dans le cas d'une machine qui a des utilisateurs systèmes stockés sur le ldap.

Les utilisateurs sont gérés par la bibliothèque de nom nommée NSS (et là). Cette bibliothèque se configure dans /etc/nsswitch.conf. En supposant qu'on ait déjà un serveur ldap avec des utilisateurs, il suffit donc de modifier ce fichier ainsi que d'ajouter un fichier de configuration spécifique à nss-ldap.

Serveur LDAP

Supposons que vous ayez déjà un serveur installé (apt-get install slapd), avec un suffixe nommé dc=linux-attitude,dc=fr.

Si vous n'avez pas encore d'arborescence avec des utilisateurs, choisissez en une, par exemple ou=people,dc=linux-attitude,dc=fr.

Et peuplons d'utilisateurs notre arbre (je ne vais pas vous apprendre le LDAP). Attention, ici il faut utiliser la classe posixAccount pour les utilisateurs que nous allons créer. Il est possible de faire autrement, mais nous verrons ça plus tard.

Créons un utilisateur avec un uid qui ne rentrera pas en conflit avec les utilisateurs existants pour mieux tester. Utilisons un groupe non ldap pour simplifier le processus (attention, posixAccount est AUXILIARY, ce qui veut dire qu'il faut une autre classe pour l'utilisateur, inetOrgPerson par exemple) :

$ ldapadd -x -D "cn=admin,dc=linux-attitude,dc=fr" -W
dn: uid=peck,ou=people,dc=linux-attitude,dc=fr
uid: peck
objectClass: posixAccount
objectClass: inetOrgPerson
cn: peckname
sn: Peck Le bogoss
uidNumber: 2000
gidNumber: 1000
homeDirectory : /tmp

NSS

Il nous faut le paquet libnss-ldap. Pour que NSS le prenne en compte, il faut éditer /etc/nsswitch.conf :

# on donne la priorité à ldap
passwd:         ldap compat

Maintenant, il faut configurer libnss-ldap, c'est un peu plus compliqué, mais le fichier de config par défaut est plein de commentaires. Voici le minimum à configurer :

# /etc/libnss-ldap.conf
base ou=people,dc=nodomain
uri ldap://127.0.0.1/
ldap_version 3

Test

Ce test doit être fait en root car nous n'avons pas tout mis en place. Nous n'avons pour l'instant défini que l'existence de l'utilisateur.

$ su - peck
$ id
# Une autre façon de faire :
$ getent passwd peck

Youhou ça marche.
Demain nous ferons un peu mieux parce que là bon, c'est léger ...

Niveau : Star Star Star Empty Empty
Résumé : sensors-detect ; sensors; hddtemp; fancontrol

Sensors

Comment connaître les différentes températures à l'intérieur de votre machine ? Il y a des capteurs, donc il y a bien une information quelque part. Linux a tous les drivers nécessaires, mais pour ceux qui se sont essayé à regarder, c'est difficile de savoir qui sert à quoi. Heureusement, il y a lm-sensors pour venir à notre secours.

Pour avoir la liste de tous les capteurs disponibles sur la machine ainsi que les driver linux associés à charger, il existe une commande toute simple une fois le paquet lm-sensors installé :

$ sensors-detect

Cette commande scanne le matériel, vous pose une question ou deux et termine en vous listant les modules noyau à charger pour pouvoir obtenir les valeurs. Deux choses à faire :

# On charge le(s) module(s)
$ modprobe lemodule
# Et on automatise ça pour le prochain reboot
$ echo lemodule >> /etc/modules

Et voilà, il ne vous reste plus qu'à lire les valeurs. Pour cela, vous avez plusieurs outils :

# lecture simple des valeurs en mode texte
$ sensors 
# lecture avec interface graphique (ne marche pas chez moi)
$ xsensors

Ou les traditionnelles applet qu'on peut trouver sur gnome, kde, gkrellm, windowmaker ...

Hddtemp

Si vous voulez aussi lire la température de vos disque, il existe hddtemp du paquet éponyme. Celui-ci marche directement en ligne de commande :

# Il faut être root
$ hddtemp /dev/sda

Il existe aussi en mode démon, une fois installé, modifiez /etc/default/hddtemp (debian) et relancez le démon :

$ /etc/init.d/hddtemp restart
# vérifions qu'il marche
$ telnet localhost 7634

Et voila, il ne vous reste plus qu'a ajouter le disque dur dans l'applet.

Attention, l'applet de gnome nécessite d'être redémarrée pour détecter hddtemp.

Fancontrol

C'est la fête, passons maintenant aux ventilateurs. Vous avez déjà remarqué que vous pouvez avoir la vitesse de rotation dans vos applet. Ajoutez la au moins temporairement, ça peut vous être utile pour la suite.

En effet, nous n'allons pas seulement lire la vitesse des ventilateurs, mais nous allons la modifier. Pour ceux qui veulent regarder sous le capot, tout cela se trouve dans /sys/devices/platform/<sensordriver>/

Fancontrol est un paquet qui contient deux choses : un script permettant de régler automatiquement la vitesse de rotation des ventilateurs et un outil permettant de le configurer sans se forcer.

Pour utiliser fancontrol, il faut avoir des sensors opérationnels. Gardez de préférence un oeil sur votre applet pour éviter les débordements de température et pour savoir quoi répondre au script.

$ pwmconfig

Ce script vous pose plein de questions, arrête les ventilateurs, les relance, les ralentit ... dans le but de savoir quel ventilateur fait quoi, à quel capteur de température on peut l'associer et comment il marche. Sachez au passage que les processeurs acceptent des températures assez élevées, pas besoin de les forcer à 40°C, vous économiserez du bruit. Regardez la doc de votre fabricant si vous voulez un avis sérieux.

Le script pose 2 questions difficiles à comprendre

  • MINSTART est la valeur de configuration au dessus de laquelle le ventilateur commence à tourner
  • MINSTOP est la valeur de configuration au dessous de laquelle le ventilateur s'arrête de tourner

De façon générale, MINSTOP doit être supérieur à MINSTART (hystérésis), mais les valeurs sont assez proches. Vous pouvez aussi choisir ces valeurs par rapport à ce que vous entendez plutôt qu'à la vitesse réelle de rotation.

Une fois le tout configuré :

$ /etc/init.d/fancontrol start

Et écoutez ce silence en provenance de votre ventilateur. Surtout lorsque vous faites des activités peu intensives.