Linux Attitude

Niveau :      
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 :      
Résumé :

Gestion des connexions

Pam_ldap dispose d'options avancées pour gérer les connexion des utilisateurs et limiter leur accès.

• Interdire certains utilisateurs sur la base d'un attribut avec pam_filter
• Vérifier la politique de mot de passe avec pam_lookup_policy
• Vérifier que l'utilisateur se connecte à une machine autorisée avec pam_check_host_attr
• Vérifier que l'utilisateur est autorisé à se connecter sur le service pam donné (exemple ssh) avec pam_check_service_attr
• Vérifier qu'un utilisateur appartient bien à un groupe pour avoir le droit de se connecter avec pam_groupdn
• Vérifier que seuls les utilisateurs créés à la main peuvent se connacter avec pam_min_uid et pam_max_uid

LDAP est capable de gérer des politiques de mot de passe, ceci fera l'objet d'un article indépendant.

Connexion sécurisées

La configuration est très bien telle quelle pour un serveur LDAP local.

A partir du moment où le serveur LDAP est distant, il peut être bon de sécuriser un minimum les communication avec le serveur. Pensez à utiliser TLS ! Tant que vous y êtes, faites-vous un certificat client pour votre machine, ça ne coûte pas grand chose.

Cache local

Pour éviter les problèmes de coupure réseau avec le serveur ldap, vous avez deux solutions :

Réplication locale du serveur LDAP

Remplissage d'une base statique

Automount home

Puisque le LDAP se comporte de notre point de vue comme NIS, il semble logique d'avoir aussi des répertoire home communs. On va donc reprendre la technologie correspondante : NFS et faire en sorte que les répertoires homes soient disponibles automatiquement sur toutes les machines.

Politique de mot de passe Option de PAM

Niveau :      
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

Niveau :      
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.

Niveau :      
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"

Niveau :      
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 :      
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 ...