Linux Attitude

Niveau :      
Résumé : HISTIGNORE ; 4.2.2.2 ; dig +trace ; setterm -dump ; echo -ne "\033]2;\07"

Supprimer les commandes potentiellement dangereuses de l'historique (qui contiennent *) et celles commençant par un espace (ignore volontaire) :

# a mettre dans le .bashrc
$ export HISTIGNORE="*\**: *"

Si vous êtes perdus, dans l'immensité d'internet sans serveur dns, souvenez vous :

# 4.2.2.2 est un serveur dns
$ host linux-attitude.fr 4.2.2.2

Si vous voulez savoir comment se déroule une requête dns complète :

$ dig +trace linux-attitude.fr

Lire le contenu de la console "(ctrl-)alt-F1" :

$ setterm -dump 1 -file dump.txt

Changer le titre de la fenêtre du terminal en cours :

$ echo -ne "\033]2;Titre ...\07"

Niveau :      
Résumé : little endian, big endian

On nous parle souvent de problèmes de petits indiens et de grands indiens, hé bien c'est du flan, les indiens n'existent pas. Si on fait exception des mal comprenant, la traduction correcte est petit boutiens, et gros boutiens. L'information nous vient de Gulliver lorsqu'il est revenu de Lilliput. Il y a rencontré un peuple divisé en deux, les premiers prétendaient qu'un oeuf devait se tenir par le petit bout alors que les autres affirmaient le contraire (à moins que ce ne soit l'opposé).

Dans l'informatique, les guerres de religions sont du même style. Par exemple, comment écririez vous cent vingt trois ? Les gros boutiens (ou bien est-ce gros boutistes ?), diraient 123 alors que les petits boutiens diraient 321.

Les premiers affirment que c'est plus logique d'avoir d'abord l'ordre de grandeur, et ensuite l'information de précision. Les seconds disent qu'il est plus intéressant de pouvoir lire les nombres d'une longueur théoriquement indéfinie, puisqu'on peut ajouter des chiffres aussi longtemps qu'on lit. En fait la différence est essentiellement affaire de religion puisque les processeurs lisent toujours des entiers de taille fixe, bien qu'il puisse y avoir un léger avantage au développement d'un processeur compatible lisant des entiers plus gros (64 bits) sur une architecture little endian.

Mais qui fait partie de quelle église (quel endianness) ?

• x68 : little endian
• sparc : big endian
• powerPC : big endian
• ARM : agnostique, supporte les 2
• PDP-11 : bi, little et big endian simultanément selon les octets considérés
• IP : big endian

Hé oui, internet et quasiment tous les réseaux ont un ordre qui est le plus gros d'abord. C'est pourquoi les fonctions ntoh* et hton* ont été définies (network to hardware et inversement).

Voila, maintenant vous savez pourquoi vous ne pouvez pas simplement transporter votre base de données (ou votre tar) de votre pentium vers votre station sparc sans avoir de problèmes ...

Niveau :      
Résumé : /etc/X11/xorg.conf ; setxkbmap

Savez-vous qu'il n'est pas nécessaire d'avoir une applet kde pour changer la configuration de son clavier ? Celle-ci est définie dans /etc/X11/xorg.conf " à la section "InputDevice". La liste des paramètres disponibles est ici.

Pour connaître les valeurs disponibles pour votre clavier :

$ less /etc/X11/xkb/rules/xorg.lst

Les lignes commençant par ! correspondent aux paramètres qu'on peut changer. Les autres lignes sont les valeurs disponibles suivies d'un commentaire. Vous avez donc la liste de tous les claviers disponibles, avec toutes leurs variantes.

Notez la section "option" (correspondant à XkbOptions ou à setxkbmap -option), on y trouve des options intéressantes comme :

• ctrl:swapcaps : qui permet d'inverser ctrl et caps lock (pour les vieux emacsiens)
• srvrkeys:none : pour interdire les combinaisons ctrl-alt (plus possible de retourner en console)
• compose:rwin : pour retrouver votre touche compose permettant de faire des caractères comme ¿

Remarquez aussi le grp dans cette section. Elle permet de contrôler la configuration simultanée de plusieurs claviers. Vous pouvez configurer plusieurs claviers simultanément en les séparant par des virgules dans les paramètres :

Option "XkbLayout" "fr,us,de"

Pour passer de l'un à l'autre, un raccourci est défini grâce à cette option grp.

# passer d'un clavier à l'autre en appuyant sur les 2 touches control
Option "XkbOptions" grp:ctrls_toggle 

La même chose en live :

$ setxkbmap -option grp:ctrls_toggle 

Chose amusante, vous pouvez indiquer l'utilisation d'un mapping alternatif avec une led en utilisant l'option "grp_led:scroll".

Je vous laisse, j'ai bloqu

Niveau :      
Résumé : sed ; kernel panic ; set -C

Récupérer les numéros de ligne correspondant à une expression régulière :

$ sed -n '/regex/=' fichier.txt

Récupérer les 3 lignes suivant une expression régulière :

$ sed -n '/regex/,+3p' fichier.txt

Faire un match sur plusieurs lignes
Grouper les lignes 3 par 3 pour faire un match:

# chaque N; ajoute une ligne au match
$ sed -n 'N;N;/ligne1\nligne2/p' fichier.txt

Faire rebooter le noyau automatiquement si un kernel panic se produit (lire aussi ce commentaire) :

# reboot après 15s
$ /sbin/sysctl -w kernel.panic=15
# le même écrit autrement
$ echo 15 > /proc/sys/kernel/panic

Interdire le shell d'écrire sur un fichier existant avec > :

# à mettre dans votre .bashrc
$ set -C

Niveau :      
Résumé : gnu ddrescue

Souvenez-vous, au premier épisode vous récupériez un disque abîmé avec dd, la technique et la répétition aidant, vous étiez passé à dd_rescue; aidé par votre (malheureusement trop) occasionnel compagnon par2.

Depuis cette époque, les gens on grandi et un petit nouveau est né. À mon avis, son auteur a fait un erreur stratégique en lui donnant presque le nom de son parrain. Il s'appelle gnu ddrescue, et seul un '_' et un gnu les séparent. Pourtant le petit nouveau a été écrit sans référence à dd_rescue.

Trêve de bavardage, récupérons ... je me coupe la parole à moi-même pour indiquer que debian met le binaire dans /sbin, mais pourquoi là ? Il n'y a pas que les admins qui ont le droit de perdre des données ! Donc, récupérons disais-je :

$ /sbin/ddrescue /dev/cdrom ~/recup.iso

Mais pourquoi utiliser celui-ci plutôt que l'autre ? Tout d'abord parce qu'il été réécrit en C et est bien plus rapide (pas de lancement de sous processus, et certaines opérations sont simplifiées). Ensuite parce que son algorithme est un peu plus intéressant. En effet, contrairement à dd_rescue, il ne cherche pas à réparer et à obtenir tout dès le début. Il fonctionne par parcours successifs du fichier à récupérer, tout d'abord avec des grosses mailles, puis de plus en plus fin. Ce qui veut dire qu'en pourcentage, vous récupérer le maximum de donnes au début, puis progressivement des parties de plus en plus détruites.

D'autre part, ddrescue peut être lancé plusieurs fois et il récupérera de nouvelles données à chaque fois. Ce qui veut dire qu'on peut prendre son temps pour la récupération (il résiste aux crash), mais aussi qu'on peut faire de la récupération à partir de plusieurs copies abîmées.

Donc pour un usage un peu plus évolué, on aura simplement besoin d'un fichier de log

# on peut lancer cette commande autant de fois qu'on veut
$ /sbin/ddrescue /dev/cdrom ~/recup.iso ~/logfile

Vous trouverez dans le man, quelques options spécifiques à certains problèmes comme -s pour limiter la taille de fichier ou -i pour commencer au milieu d'un disque.

Enfin, n'oubliez pas, dans le cas d'une récupération d'un système de fichier, il vaut mieux laisser fsck bidouiller sur une copie pour pouvoir recommencer avec d'autres outils.

Niveau :      
Résumé : asciidoc

Aujourd'hui évitons de réinventer la roue. Si vous cherchez à écrire un langage de présentation simplifié (bbcode, dotclear, mediawiki, doku wiki et les centaines de sortes de wiki existantes), laissez tomber et prenez quelque chose qui existe. Je vais vous en présenter un parmi tant d'autres, un qui a l'avantage d'être parfaitement lisible directement en mode texte.

Supposons que vous ayez un petit texte à écrire pour votre usage personnel (mémo, post-it, article de blog, mail ...). Écrivez le simplement sous la forme qui vous semble naturelle dans un éditeur de texte :

Mes courses
===========

Fauchon
-------
* Fraisier
* Chocolats

Foucher
-------
* Rochers noirs
* Cerises

Et voila, vous avez la partie texte, éditable et lisible.

Vous le voulez en html ?

$ asciidoc -b html4 fichier.txt

Vous le voulez en pdf ?

# on passe par du docbook
$ asciidoc -b docbook fichier.txt
$ docbook2pdf fichier.xml

En fait asciidoc ne supporte nativement que xhtml 1.1, docbook et html 4, mais le docbook permet de sortir dans pla plupart des formats de fichiers (y compris odf :-).

Notez que le manuel complet d'asciidoc a été écrit en asciidoc. Il a l'air long, mais seuls les chapitres 7 à 13 sont utiles pour les cas courants.

Alors de grâce n'inventez plus de nouveau langage, celui-ci suffit amplement. Il est tellement simple à lire et à écrire que je connais une entreprise qui l'utilise exclusivement pour sa documentation interne ! Vous pouvez envoyer vos documentations par mail, diff et patch fonctionnent, vous pouvez les publier proprement (css est votre ami), vous n'avez pas besoin d'un gigaoctet de ram pour l'éditer puisque vi suffit et enfin vous pouvez l'éditer depuis les modems 9600bps du Népal.