Pour vérifier le bon fonctionnement de votre démon ntp, vous êtes amené à taper la commande suivante qui liste les source de temps utilisées :

$ ntpdc -p

Cette commande met une étoile face à la source de référence utilisée pour la synchronisation. Le choix se fait entre autre en fonction du stratum de la source. Je rappelle que les serveurs NTP disposant d'une source de temps matérielle fiable (horloge atomique) ont pour stratum 1. Ceux qui se synchronisent sur eux, 2, et ainsi de suite.

Étant donné qu'il y a un grand nombre de serveurs publics de strate 2 et 3, vous devriez avoir accès à des serveurs de strate 4, ou au pire 5. Mais si le serveur a une strate plus élevée, il se peut que l'horloge choisie ne soit plus le serveur, mais l'horloge locale qui a une strate définie par défaut à 5 sur certaine distributions.

Et là c'est le drame, vous n'êtes plus synchronisés !

Pour résoudre ce problème, il y a plusieurs méthodes, se résumant toutes en la configuration des serveurs de temps :

# ntp.conf

# mettre l'option prefer sur le serveur voulu
serveur xxx.com prefer
# réduire la strate du serveur
fudge xxx.com stratum 4

# augmenter la strate de l'horloge locale
# 127.127 pour les horloges non réseau
# 1.0 pour l'horloge système
fudge 127.127.1.0 stratum 10

Si vous avez aimé, il y a aussi :

1. Il faut laisser le temps au temps
2. Verrou virtuel

Vous avez vu apparaître dans l'article sur tmux, un petit outil pour verrouiller le terminal, il s'appelle vlock.

Son unique fonctionnalité est le locker un terminal et de demander un mot de passe pour être débloqué.

Mine de rien ça lui fait quand même deux cas d'usage :

• bloquer l'accès physique à une machine
• bloquer l'accès virtuel à un shell

Virtuel

Avec la commande suivante :

$ vlock

Vous bloquez votre terminal en cours, et seul un mot de passe peut le débloquer. C'est utile essentiellement lorsque vous êtes connecté en ssh à distance sur une machine.

Physique

L'option -a permet de locker toutes les consoles locales (ctrl-alt-Fx, ou alt-Fx), en pratique il locke la console en cours et empêche d'en changer. Il faut donc déjà être sur une console locale.

Si vous êtes sur X, vous êtes aussi sur une console locale (remarquez le ctrl-F7 pour y aller). Mais le shell qui va lancer votre commande ne l'est pas, il est dans le terminal virtuel de xterm, rxvt, konsole et consorts. Pour locker toutes les consoles, il faut donc utiliser l'option -n qui ouvre une nouvelle console (avec openvt) avant de continuer avec l'option -a.

Enfin notez que l'utilisateur local a en général accès aux magic keys, et une de ces magic keys sert justement à tuer le processus en avant plan (alt-sysrq-k), par exemple pour garantir qu'il n'y a pas de keylogger. Si vous ne voulez pas vous faire tuer votre session par cette combinaison de touche vous pouvez utiliser l'option -s. C'est là qu'on voit que cette combinaison nommé SAK n'est pas si sécurisée que ça puisqu'elle peut être désactivée...

Donc je résume :

# en tant qu'utilisateur normal et seulement depuis une console texte
$ vlock -a
# en tant que root
$ vlock -sn

Quand le lancer

Et c'est là qu'est la difficulté, en toute logique le lancement doit se faire par le processus qui dispose du terminal à un instant donné, surtout dans le cas de blocage du terminal virtuel. La bonne solution est de le lancer après un certain temps d'inactivité, et seule l'application peut savoir quand le lancer. C'est donc à vous de trouver les settings spécifiques à l'application pour le faire.

Mon article précédent indique comment faire pour tmux, malheureusement je n'ai pas trouvé de solution pour bash qui ne propose que la variable TMOUT qui termine complètement le shell.

Si vous avez aimé, il y a aussi :

1. Login dans un chroot
2. Poisson de janvier
3. Clavier virtuel

Comme disait un illustre au grand cœur, "Compromis, chose due !" (orthographe approximative). Voici donc mon fichier de configuration détaillé de tmux, à mettre dans ~/.tmux.conf ou /etc/tmux.conf au choix. Je n'ai pas changé beaucoup de raccourcis car je tiens à m'habituer autant que possible aux valeurs par défaut qui vont se retrouver sur mes nouveaux serveurs.

J'en profite pour ajouter un raccourci que j'ai oublié la dernière fois :

• ctrl-b D : pour détacher un tmux resté ouvert à distance

# Pour les nostalgiques de screen
# comme les raccourcis ne sont pas les mêmes, j'évite
#set -g prefix C-a
#unbind-key C-b
#bind-key a send-prefix

# même hack que sur screen lorsqu'on veut profiter du scroll du terminal (xterm ...)
set -g terminal-overrides 'xterm*:smcup@:rmcup@'

# c'est un minimum (defaut 2000)
set-option -g history-limit 100000

# lorsque j'ai encore un tmux ailleurs seule
# sa fenetre active réduit la taille de ma fenetre locale
setw -g aggressive-resize on

# locker la session après inactivité (en s)
set -g lock-after-time 3600
# pour que le lock marche sous linux (apt-get install vlock)
set -g lock-command vlock

# il faut choisir un derivé de screen, 256 couleurs c'est bien !
set -g default-terminal "screen-256color"

# pour ceux qui n'ont pas laché la souris
set -g mouse-select-pane on
setw -g mode-mouse on

# ca peut etre utile ...
set -g status-utf8 on
setw -g utf8 on

# Pour etre alerté sur un changement dans une autre fenêtre
setw -g monitor-activity on
#set -g visual-activity on
#set -g visual-bell on

# numéroter a partir de 1, pratique pour l'accès direct
set -g base-index 1

# repercuter le contenu de la fenetre dans la barre de titre
# reference des string : man tmux (status-left)
set -g set-titles on
set -g set-titles-string '#H #W #T' # host window command


#########
# theme #
#########
# exprimez votre créativité ici !
# pour les string : man tmux (status-left)

# barre un peu plus discrete
set -g status-bg default
set -g status-fg green
setw -g window-status-current-bg default
setw -g window-status-current-fg white
setw -g window-status-alert-attr default
setw -g window-status-alert-fg yellow

set -g pane-active-border-fg green
set -g pane-active-border-bg black
set -g pane-border-fg white
set -g pane-border-bg black

set -g message-fg black
set -g message-bg green

# exemples de barre d'état 
#set -g status-left '#[fg=red]#H#[fg=green]:#[fg=white]#S #[fg=green]][#[default]'
#set -g status-right '#[fg=green]][#[fg=white] #T #[fg=green]][ #[fg=blue]%Y-%m-%d #[fg=white]%H:%M#[default]'

#set -g status-left '#[fg=red]#H#[fg=green]:#[fg=white]#S #[fg=green]][#[default]'
#set -g status-right '#[fg=green]][ #[fg=blue]%Y-%m-%d #[fg=white]%H:%M#[default]'

#set -g status-left '#[fg=green](#S) #(whoami)@#H#[default]'
#set -g status-right '#[fg=yellow]#(cut -d " " -f 1-3 /proc/loadavg)#[default] #[fg=blue]%H:%M#[default]'

#set -g status-right "#[fg=yellow]#(uptime | cut -d ',' -f 2-)"

Comme pour le bashrc collaboratif, je vous propose de poster en commentaires vos personnalisations, je les ajouterai.

Si vous avez aimé, il y a aussi :

1. Screen killer
2. Geek et partage
3. Prompt String

Aujourd'hui tout le monde connaît et utilise screen. Miracle de la technologie, il permet de survivre aux déconnexions, de lancer des commandes longues sans avoir peur, de faire passer tous ses shells dans une seule connexion et on le trouve souvent associé à l'indémodable irssi.

Comme vous le savez peut-être screen n'est plus maintenu. Ayant un code un difficile à lire et à maintenir, des développeurs ont choisi lui faire un concurrent plutôt que de le reprendre.

Ce concurrent se nomme tmux. Il dispose de la plupart des fonctionnalités de screen et d'autres en plus. Comme vous le verrez, votre problème sera essentiellement de vous adapter aux nouveaux raccourcis. Pour le reste c'est tout bon.

Tmux dispose de presque toutes les fonctionnalités de screen sauf la communication par port série (rapport choucroute, toussa).

Commençons par le lancement :

# lancer un nouveau multiplexeur
$ screen 
$ tmux
# s'attacher à un multiplexeur existant 
$ screen -d -r
$ tmux attach

Les raccourcis :

• Nouvelle fenêtre
  • screen : ctrl-a ctrl-c
  • tmux : ctrl-b c
• Se détacher :
  • screen : ctrl-a d
  • tmux : ctrl-b d
• Passer à la fenêtre suivante
  • screen : ctrl-a <espace>
  • tmux : ctrl-b n

Je dois dire que ça y est je suis passé entièrement à tmux, le mélange ctrl-a ctrl-b entre screen et tmux commençait à être difficile. A propos d'adaptation, j'ai eu une seule difficulté c'est de m'habituer au nouveau scrollback. Il n'est pas possible de le faire à la souris, comme dans screen avec l'astuce du termcapinfo. Remarquez, c'est plus propre car du coup il n'y a pas de mélange des bufffer de scrollback entre les différents terminaux. Donc la méthode propre dans tmux c'est ctrl-b suivi de pgUp et là vous êtes en mode copy (qui permet entre autre le scrollback), vous pouvez alors naviguer avec pgUp, pgDown ou les touches directionnelles. Et pour Revenir au mode normal, Esc tout simplement.

Dans un prochain article nous verrons comment changer la configuration de tmux, même si les valeurs par défaut sont plutôt bonnes.

Si vous avez aimé, il y a aussi :

1. Screen et irssi
2. Configuration de tmux
3. Geek et partage

Pour ceux qui voudraient essayer le parachutisme, je vous le conseille, c'est très fort ! Par contre ça vous empêche d'écrire des articles ...

Vous venez de faire un chroot et vous voulez pouvoir vous connecter dessus comme s'il s'agissait de votre machine locale ?
Pas de panique, c'est tout simple.

Pour cela nous allons regarder 3 méthodes différentes de connexion à votre chroot : le terminal local, ssh et l'environnement graphique. Mais avant tout préparons le chroot à ressembler à une distribution normale.

$ mount --bind /dev $CHROOT_BASE/dev
$ mount --bind /proc $CHROOT_BASE/proc
$ mount --bind /sys $CHROOT_BASE/sys

Terminal local

Pour se connecter en local à votre machine, vous utilisez les consoles disponibles (alt-Fx ou ctrl-alt-Fx si vous êtes en mode graphique). Vous en avez 6 à disposition.

Pour faire simple, nous allons juste faire en sorte que les consoles 4 à 6 redirigent dans le chroot tandis que les 1 à 3 resteront dédiées à la machine principale.

Il suffit de modifier /etc/inittab :

# /etc/inittab
1:2345:respawn:/sbin/getty tty1
2:2345:respawn:/sbin/getty tty2
3:2345:respawn:/sbin/getty tty3
4:2345:respawn:chroot <CHROOT_BASE> /sbin/getty tty4
5:2345:respawn:chroot <CHROOT_BASE> /sbin/getty tty5
6:2345:respawn:chroot <CHROOT_BASE> /sbin/getty tty6

Et là, soit vous redémarrez (bof on n'est pas sous windows) soit vous forcez init à relire sa configuration :

# en root
$ telinit q
$ pkill getty

Et maintenant passez à la console 4 (ctrl-F4) et vous pouvez vous connecter avec votre utilisateur intérieur au chroot.

SSH

Si vous vous connectez à votre machine en ssh, vous pouvez vouloir faire de même pour votre chroot.

Pour ce faire, vous pouvez lancer un service ssh à l'intérieur du chroot. Tout simplement :

$ chroot $CHROOT_BASE
$ apt-get install openssh-server

Par contre vous ne pouvez pas laisser ssh tourner sur le même port que le ssh qui tourne déjà. Utilisez donc un autre port, par exemple le 1022 :

$ vi $CHROOT_BASE/etc/ssh/sshd_config
> Port 1022

Puis lancez ssh dans le chroot :

$ chroot $CHROOT_BASE /etc/init.d/ssh restart

Vous pouvez maintenant vous connecter directement au chroot :

$ ssh -p 1022 user@leserveur.com 

GDM

Maintenant si votre habitude est d'avoir un environnement de bureau comme gnome, il faut faire pareil pour lui.

Tout passe par le login manager. Je prends l'exemple de GDM, mais vous pouvez faire la même chose avec KDM.

Tout d'abord, vous devez avoir un gdm d'installé dans le chroot, donc un environnement graphique minimal.

Une fois installé dans le chroot, par exemple avec :

$ chroot $CHROOT_BASE apt-get install gnome

Éditez le fichier de configuration de gdm $CHROOT_BASE/etc/gdm/gdm.conf :

[daemon]
# ceci devrait être inutile, mais on ne sait jamais
FirstVT=8

[server]
0=Standard device=/dev/console

Relancez gdm dans le chroot :

$ chroot $CHROOT_BASE /etc/init.d/gdm restart

Et voilà, rendez-vous sur la console 8 (ctrl-alt-F8) pour obtenir un login graphique dans le chroot. Sur la console 7 (ctrl-alt-F7) le login original est toujours disponible.

Si vous avez aimé, il y a aussi :

1. Configuration de init
2. Chroot
3. Chroot toujours

Aujourd'hui un truc obscur pour beaucoup d'entre nous : alsa. Pas la poudre blanche, mais le truc avec un mixer, enfin pas celui de la cuisine, mais celui de linux ...

Pour simplifier disons que alsa est une API présentée par le noyau et qui permet d'accéder à travers une interface unique à toutes les cartes son que vous pouvez avoir.

Fichier de configuration

Alsa étant relativement bien fait, ses utilisateurs (l'application qui émet du son, la gestion du volume ...) n'ont pas besoin de configuration particulière pour fonctionner. Mais il est possible de changer cette non configuration. Cela peut se faire soit de façon globale au système dans /etc/asound.conf soit spécifiquement à l'utilisateur dans ~/.asoundrc.

Que peut-on mettre dans ces fichiers ?

Là ça devient vite obscur et peu documenté. Mais nous allons voir que c'est assez simple. Il s'agit d'une configuration hiérarchique. Vous avez le choix entre les 2 formats suivants pour écrire des valeurs (ou un mix des 2) :

# commentaire
val.eur.1 "toto"
val.eur.2 "tata"
val.ue "help"

val {
  eur {
   1 "toto"
   2 "tata"
  }
  ue "help"
}

Éléments de configuration

Mais que peut-on bien mettre dans ce fichier ?

Ici les exemples sont nombreux, mais rarement expliqués.

Tout d'abord une liste détaillée se trouve ici : Asoundrc.txt

Reste à trouver ce que les attributs veulent dire. Ce qui va vous intéresser est essentiellement pcm qui permet de créer une nouvelle carte son (virtuelle). Les autres ne vous seront utiles que rarement et dépendront surtout du contenu de vos pcm.

Un pcm

La première chose à déclarer dans un pcm est son type, vous avez le choix parmi les différents plugins alsa. Contemplez la densité de la documentation, heureusement vous en avez un peu plus ici : pcm_plugins.html

Notez la présence de ladspa pour changer le pitch du son. J'ai déjà présenté son usage avec vlc pour accélérer un son sans en changer la hauteur.

Chaque type a ses paramètres spécifiques. Tous les plugins qui ne font que traiter le signal (comme ladspa ou softvol) ont un paramètre slave. Il faut bien comprendre de que cela signifie. Un slave est un autre plugin (oui c'est sans fin :-) qui va recevoir le son depuis le plugin que l'on configure. Donc le son transite de master vers slave lors de la lecture mais il transite de slave vers master lors de l'enregistrement.

Exemple

Maintenant prenons un exemple utile, ajouter une pré-amplification logicielle au système. Pratique lorsqu'on a un portable et qu'aucun ampli externe ne nous permet de monter le son alors que c'est l'enregistrement de youtube qui est très faible.

Comment faire ? Très simple, ajoutons une carte virtuelle de type softvol

pcm.softcard {
      type softvol
      slave.pcm "default"
# on associe un contrôle nommé pre-amp au mixage de la première carte son
      control.name "Pre-Amp"
      control.card 0 
}

C'est bien, mais cela veut dire qu'il faut indiquer à nos logiciels d'utiliser la carte softcard pour profiter de cet avantage. Quelques changements vont nous permettre de changer ceci pour tout le monde.

# on change la configuration du pcm par défaut
pcm.!default {
      type plug
# et on pointe bêtement vers la notre
      slave.pcm "softcard"
}

pcm.softcard {
      type softvol
# on laisse dmix choisir la bonne carte physique
      slave.pcm "dmix"
      control.name "Pre-Amp"
      control.card 0
# on en profite pour donner des limites plus sympa pour l'augmentation et la rédution du volume
      min_dB -5.0
      max_dB 20.0
      resolution 5
}

Avant de voir le contrôle, il faut lancer un premier test pour forcer la lecture du fichier de conf par alsa (c'est comme ça ...) :

# test de bruit presque blanc
$ speaker-test

Et maintenant nous avons un nouveau contrôle dans alsamixer (ou votre mixer préféré) permettant de régler la pré-amplification.

A vous de tester les autres plugins ...

Si vous avez aimé, il y a aussi :

1. MPD (Music Player Daemon)

Exécution

Savez-vous qu'on peut rendre n'importe quel fichier exécutable sous linux ? Bien sûr il suffit de faire un chmod +x, mais le noyau risque de vous envoyer balader si le fichier n'est pas réellement exécutable.

Mais je parle ici de rendre exécutable n'importe quel fichier, un jar, un source en C, un MP3 ...

Mais comment quoi que donc !?

Pour exécuter un fichier, le noyau lit les premiers octets du fichier et vérifie qu'ils correspondent à un format binaire (binfmt) connu. Il existe un système pour ajouter des formats binaires à ceux déjà supportés dans le noyau (en gros les elf et les scripts). Il s'agit du format misc.

Pour savoir si ce format est supporté chez vous, ce qui est très probable, lancez la commande :

$ cat /proc/sys/fs/binfmt_misc/status

S'il n'est pas supporté, il faut charger le module et monter le répertoire :

$ modprobe binfmt_misc
$ mount binfmt_misc -t binfmt_misc /proc/sys/fs/binfmt_misc 

C capital

Maintenant supposons vous vouliez rendre les fichiers .c exécutables. Vous pouvez soit utiliser un de mes anciens articles ... soit créer un petit script qui sera appelé à chaque exécution d'un .c :

#!/bin/sh
# /usr/local/bin/ccexec
gcc -Wall -o /tmp/cscript.$$ "$1" && shift && /tmp/cscript.$$ "$@"
ret=$? ; rm -f /tmp/cscript.$$ ; exit $ret

Et de faire en sorte qu'il soit réellement appelé :

$ echo ':cfile:E::c::/usr/local/bin/ccexec:' > /proc/sys/fs/binfmt_misc/register

Hop un test :

#include <stdio.h>
// test.c
int main() {
  printf("Coucou\n");
  return 0;
}

Et on lance :

$ chmod +x test.c
$ ./test.c
> Coucou

Yeah !!!

G tout compris

Maintenant, passons à l'exécution d'un gzip. Plutôt que de reconnaître le fichier à son extension, ce qui est franchement faible comme méthode nous allons vraiment détecter le type de fichier.

Allons voir la spécification, un fichier gzip se reconnait à ses 2 premiers octets qui doivent valoir 0x1f et 0x8b :

$ echo ':gzip:M::\x1f\x8b::/bin/gunzip:' > /proc/sys/fs/binfmt_misc/register

Même méthode et ça marche. Notez qu'il est possible d'utiliser n'importe quel champs de bits grâce à une masque et une position de départ, mais seulement dans les 128 premiers octets du fichier.

Enfin, certaines distributions vont vous installer des choses un peu plus utiles comme l'exécution des jar avec java ou celle d'exécutable windows avec wine.

Et pour une spécification plus détaillée de ce qu'il lest possible de mettre dans la ligne d'enregistrement, direction la documentation

PS : pour supprimer l'entrée : echo -1 > /proc/sys/fs/binfmt_misc/cfile

Si vous avez aimé, il y a aussi :

1. #!/usr/bin/gcc (bis)
2. Changer la priorité d’exécution des processus
3. Trucs et astuces (5)