Linux Attitude

Yooooo,

Désolé pour ceux qui pensaient que ce site partait à l'abandon, ce n'est pas le cas, juste un ralentissement.

Tout d'abord, plusieurs personne m'ont rapporté une disparition de commentaires il y a une semaine ou deux. C'est probablement dû à une erreur de manipulation liée aux spams (hé oui, ils nous suivent à la trace). Donc pour information, j'ai désactivé totalement les trackbacks. Et si votre commentaire a disparu, repostez-le vous serez sympa.

Pour ceux qui ne seraient pas au courant, ce site a soufflé sa première bougie il y a quelques jours. Si vous vous ennuyez, relisez les premiers articles, je suis sûr que vous en avez oublié le contenu, et pourtant ils sont tout aussi intéressants que celui de la semaine dernière. En attendant un design plus adapté à la lecture linéaire des articles, vous devrez cliquer sur archives.

Ce site a aussi fêté son premier invité, vous l'aurez remarqué, le dernier article n'est pas de moi. J'aurais cru voir plus d'intérêt pour un post si passionnant ...

Et enfin, comme ne le veut pas la tradition, je vous dévoile le prochain sujet : un truc sur linux !

Niveau :      
Résumé : clusterssh, clusterm, konsole, dsh, pssh

Bonjour à tous, très honoré d'être à la tribune de ce blog, mais on m'a forcé la main !

Pour rebondir sur un post récent (tout juste un an !), voici quelques outils pour travailler efficacement sur un groupe de machines.

Konsole et dsh, les ancêtres

Comme Peck l'avait présenté, pour envoyer une même suite de commandes sur un groupe de machines, on peut soit le faire à l'aveugle avec Konsole (si on supporte KDE), soit lancer ses commandes coûte que coûte avec dsh, mais sans contrôle encore une fois sur le déroulement.

Avec Konsole : préparez dans une même fenêtre une machine à contrôler par onglet, puis dans les menus : View > Send Input to All Sessions. Désormais, tout ce que vous tapez est répété dans toutes les fenêtres.

Avec dsh :

 dsh -m machine1 -m machine2 commande

Attention, n'oubliez pas que votre commande est d'abord interprétée par votre shell. Ainsi, comparez :

 dsh -m machine1 -m machine2 -m ... "echo $HOSTNAME"
 dsh -m machine1 -m machine2 -m ... 'echo $HOSTNAME'

Relisez l'article pour apprendre comment créer des groupes de machines avec dsh.

clusterssh et clusterm

Mais si on désire surveiller ce qui se passe sur toutes les machines, et ainsi avoir un contrôle visuel, et au besoin effectuer une correction sur une machine en particulier, alors des outils graphiques rendent bien service, en affichant dans un terminal distinct chacune des machines que l'on contrôle. Par ici pour des captures d'écran, et un petit article de présentation de clusterssh !

Vous pouvez définir vos groupes de machines dans le fichier /etc/clusters :

groupe1 machine1 machine2 machine3 machine4 machine5 machine6 machine7 machine8 machine9
groupe2 machine10 machine11 machine12 machine13 machine14 machine15
all groupe1 groupe2

Niveau :      
Résumé : locale ; export LANG ; AcceptEnv ; SendEnv

Je vais devoir arrêter les voyages, hier, je change de locale, aujourd'hui je me connecte ... rien !

Une locale c'est tout un ensemble de choses qui permettent de faire en sorte que les logiciels s'affichent dans la langue qui vous convient. Pour les développeurs, j'ai un début d'explication sur la technique.

Et ça commence par des variables locales. La première c'est LANG, qui définit la façon par défaut d'afficher les informations. Cette méthode peut ensuite être surchargée finement avec les variables LC_*, par exemple LC_MONETARY permet de changer spécifiquement l'affichage de la monnaie. Et enfin, toutes ces valeurs peuvent encore être surchargées globalement et d'un coup par la variable LC_ALL.

Étant des variables d'environnement, ces infos sont transmises de processus en processus. Donc de shell en commande. Pour connaître la locale en cours, c'est simple :

$ locale

Pour la changer :

# on liste les locales disponibles
$ locale -a
# on en choisit une
$ export LANG=fr_FR

À ajouter dans votre .bashrc pour conserver la chose un peu plus longtemps (attention, gnome et kde et caetera sont à configurer séparément).

Pour changer ceci de façon globale, ben c'est pas gagné, selon les distributions et les softs, tous n'utilisent pas les même fichiers de configuration. Tout d'abord, il y a l'historique /etc/environment, pour les shells on peut aussi chercher dans /etc/profile. Et ensuite, mais c'est spécifique debian, il y a /etc/default/locale.

Pour les systèmes utilisant pam (su, login, kdm, gdm, ...) vous pouvez aller lire les /etc/pam.d/XXX qui peuvent contenir une ligne du type :s

auth    required        pam_env.so readenv=1 envfile=/etc/default/locale

indiquant où chercher vos variables.

Et enfin, parlons ubiquité, je ne sais pas vous, mais moi je suis partout, j'ai un compte sur toutes les machines (si je n'en ai pas chez vous, appelez-moi, j'accepterai volontiers un compte, de préférence root, mais je ne voudrais pas déranger). Je suis tout d'abord chez moi, avec ma locale, et donc mon terminal adapté à cette locale (hé oui, pensez iso vs utf8) et je me connecte en ssh sur un de mes comptes. Je voudrais bien rester moi-même et garder mes locales et non pas prendre celle du système ou devoir configurer chacun des shells de destinations à la main. Heureusement, ssh a aussi prévu ce cas. Il permet la transmission des locales s'il est configuré correctement.

Sur le serveur, dans /etc/ssh/sshd_config :

# on autorise le client a jouer avec les locales à la connexion
AcceptEnv LANG LC_*

Sur le client, de préférence dans /etc/ssh/ssh_config :

Host *
# on envoit nos locales au serveur
    SendEnv LANG LC_*

Et voilà, pour peu que votre /etc/pam.d/ssh ne contienne pas de référence à un fichier qui forcerait les locales, vous êtes chez vous.

Niveau :      
Résumé : ln ; ln -s ; mount --bind

Pour ceux qui ne sont pas adeptes du lien symbolique dans le chroot et pour ceux qui veulent pouvoir se permettre de faire plusieurs chroots du même type (apache) il existe une alternative.

Des liens

Tous d'abord présentons les liens.

Le lien symbolique :

$ ln -s source destination

• Même cassé il existe encore
• Il fonctionne de n'importe où vers n'importe où, à la seule restriction que le système de fichier de destination doit les supporter (en gros tous sauf fat et ntfs)
• Attention, il peut être cassé si on supprime la source
• Attention, les droits sont gérés sur la source ET sur la destination
• Ne fonctionne pas de l'intérieur d'un chroot vers l'extérieur

Le lien dur :

$ ln source destination

• Ne se casse pas
• On peut supprimer indifféremment source ou destination sans perdre les données
• Ne fonctionne (sauf exception) sur les répertoires
• Ne peut être fait que si source et destination sont sur le même système de fichier
• Ne fonctionne pas sur certains systèmes de fichier (notamment fat et ntfs, mais pas seulement)
• Attention, les droits peuvent être différents entre source et destination, c'est le droit du fichier utilisé pour l'accès qui sont pris en compte

Le lien de montage :

$ mkdir destination
$ mount --bind source destination

• Ne fonctionne que sur les répertoires
• Fonctionne partout
• Il faut les ajouter dans /etc/fstab pour qu'ils soient maintenus au reboot
• Attention aux effets de bord, s'il y a un point de montage dans un sous répertoire de source, il ne se retrouvera pas dans destination

De leur usage

Intéressons nous aux liens de montage. Ils sont bien utiles :

• Pour faire de simple liens

• Pour dupliquer un répertoire du système vers un chroot

$ mount --bind /usr/share/php /srv/chroot/usr/share/php

• Pour faire apparaître des fichiers par un point de montage :

# on regarde ce qui se passe
$ mount 
> /dev/sda1 on / type ext3 (rw)
$ ls /home
> a b c

# on monte une partition par dessus /home
$ mount /dev/sda2 /home
$ ls /home
> d e f

# et on récupère l'ancien home
$ mount --bind / /mnt
$ ls /mnt/home
> a b c

Pratique pour récupérer la place après avoir transféré un simple répertoire dans une nouvelle partition.

Bonjour,

Cela fait bientôt un an que je tiens ce site. Comme vous avez pu le constater, j'ai du réduire un peu la cadence. Mais je ne suis pas à court d'idées pour autant. C'est juste que j'écris bien plus lentement que je n'ai d'idées d'article.

Une personne s'est déjà proposée pour écrire quelques articles sur ce site (si tu me lis, maintenant tu vas être obligé d'écrire). Si vous aussi, vous trouvez que ce site n'avance plus assez vite, vous pouvez y participer. Si vous n'avez pas d'idées, je peux vous en proposer un grand nombre.

Et que penseriez-vous d'une évaluation des articles par les lecteurs ?

Niveau :      
Résumé : mount -o resuid ; tune2fs -m ; tput ; hexedit ; vim ; xxd

Des problèmes de place sur une partition ? Si vous avez une partition ext2 ou ext3 et que vous avez de l'espace réservé, utilisez-le. Mais si vous pensez que cet espace est réservé à root, vous vous trompez :

# on peut l'allouer à un autre utilisateur
$ id user
> 1234
$ mount /home -o remount,resuid=1234

Toujours des problèmes de place ?

# on peut aussi libérer ou reprendre de la place (ici on réserve 4% de l'espace, au lieu de 5% par défaut)
$ tune2fs -m 4 /dev/sda1
$ mount -o remount /dev/sda1

Pour trouver la taille du terminal, si vous êtes en bash vous avez

$ echo $COLUMNS
$ echo $LINES

Mais si vous ne l'êtes pas vous avez tput :

$ tput cols
$ tput lines

Pour éditer un fichier en hexadécimal vous avez le choix entre un outil dédié :

# en provenance du paquet hexedit
$ hexedit fichier

Mais vous pouvez aussi utiliser un outil déja installé sur a plupart des plateformes : vim

$ vim fichier
:%!xxd
# et lorsque vous voudrez revenir à la normale
:%!xxd -r

Mais attention cet éditeur est un peu limité, seules les modifications hexa sont prises en compte, et il faut nécessairement revenir à la normale pour sauvegarder.

Niveau :      
Résumé : chroot apache2

Puisqu'on me met au défi, je vous propose de chrooter apache sans devoir installer un chroot debian complet. Tout comme pour bind, la technique n'est pas spécifique debian et vous pourrez facilement l'adapter à votre situation, de plus elle marche aussi pour apache 1.3.

Pour commencer, il vous faut un apache (2 c'est aussi bien) ainsi que l'outil miracle : mod_chroot. Celui-ci se trouve chez debian dans le paquet libapache2-mod-chroot. Son comportement est simple, il imite celui de bind. Il attend que l'application soit chargée pour effectuer l'appel système chroot(2), ce qui fait qu'il ne nécessite pas d'avoir toutes les dépendances du binaire dans le chroot.

Maintenant configurons-le, la notion de chroot étant globale au serveur apache en entier, c'est /etc/apache2/apache2.conf que nous allons modifier. Il suffit d'ajouter la ligne :

ChrootDir /srv/http

En supposant que vous avez chargé le module (avec a2enmod de préférence sous debian et une ligne LoadModule pour les autres), c'est presque fini. Vous devez maintenant relire toute votre configuration, car certaines directives sont relatives au nouveau root. En particulier les directives DocumentRoot et Directory (en pratique tous les fichiers lus dynamiquement)

Ensuite vous aurez besoin d'un minimum de fichiers dans ce chroot, heureusement ce minimum est très léger. Il nous faut un répertoire /var/run et l'accès au pid depuis l'intérieur et l'extérieur du chroot :

mkdir -p /srv/http/var/run
# attention, un lien symbolique dans l'autre sens ne fonctionnerait pas
# utilisez http.pid sur une redhat
ln -s /srv/http/var/run/apache2.pid /var/run/apache2.pid

Et voilà !!!
N'oubliez pas de mettre les données du site dans votre nouveau chroot.

Des racines profondes

Vous avez votre chroot utilisable directement depuis l'extérieur du chroot avec les scripts d'init naturels. Mais attention, quelques petites restrictions :

• les commandes reload et force-reload ne marcheront pas
  • pour cette raison, vous devrez aussi modifier votre configuration de logrotate
• les cgi ne fonctionneront pas tels quels, ils doivent être placés intégralement (avec leurs dépendances) dans le chroot
  • en particulier suexec pour php
• les modules peuvent avoir besoin de lire des fichiers, attention à bien convertir leur configuration
  • en particulier php
  • les modules pear installables tels quels avec la commande pear
• par défaut php/mysql utilise une socket unix pour parler a localhost, vous devez modifier vos scripts pour utiliser explicitement une connexion à 127.0.0.1 si besoin (ou dire a mysql de stocker sa socket dans /srv/http/tmp)
• apache mpm worker a besoin d'une bibliothèque supplémentaire dans le chroot