Il peut être très utile d'avoir sur disquette un noyau pour booter dessus. Pour faire cela, prenez une disquette formatée et allez à la racine de votre disque.
Identifiez votre noyau. Il doit s'appeler zImage ou vmlinuz.
Vous le copiez d'abord sur disquette :
cat /zImage > /dev/fd0
puis faîtes (exemple) :
rdev zImage /dev/hda2
Le deuxième paramètre doit être le nom de la partition racine
Linux de votre système.
Cette disquette vous permet alors de booter (tester !).
En bref : vous avez perdu le mot de passe de root... Bon, il y a plusieurs solutions. La première :
mount -t ext2 /dev/hda1 /mnt/mnt. Il ne reste plus
qu'à éditer le fichier /mnt/etc/passwd, y supprimer le mot de passe
de root : root::0:0:root:/root:/bin/bash.Vous rebootez Linux normalement, et en principe, vous n'avez plus besoin de mot de passe pour se loguer en root.
Bon, passons à d'autres solutions : Rebooter le pc en mode dit
single-user. Pour cela, lors du boot avec LILO, fournir LILO:
linux single (remplacer ici "linux" par le nom sous lequel LILO
connaît votre noyau). Un shell root va apparaître . Attention : le clavier
est en qwerty et la partition en lecture seule. Pour y remédier :
loadkeys /usr/lib/kbd/keytables/fr.map
mount -w -n -o remount /
Soit vous utilisez la commande passwd, soit vous éditez
le fichier /etc/passwd
Si vous n'avez pas de disquette de boot, vous pouvez souvent
vous en sortir en passant init=/bin/sh lors de l'amorçage.
Ensuite, monter la racine et éditer à la main le fichier
/etc/passwd.
Le problème du reboot en single user, c'est que
n'importe qui peut alors réussir à passer sur la machine en root. Pour les
entreprises ou les universités, cela pose un problème de sécurité.
Certaines stations Unix permettent de mettre un mot de passe dans l'EPROM
de la machine. Linux permet de demander le mot de passe root même en
single-user.
Pour cela, vous devez récupérer les sources du programme init qui est
lancé lors de l'amorçage du système. Au début du programme init.c,
modifiez, la définition de la constante SOME_USER pour qu'elle
ait la valeur 2, recompilez init, et ré-installez-le.
Cette première solution peut toutefois s'avérer être insuffisante
car une personne peut toujours booter sur un autre périphérique (en utilisant
l'option root = MonLinux).
En utilisant Lilo, pas de problème ! Il suffit alors d'ajouter
les lignes suivantes pour chacune des images dans le
fichier /etc/lilo.conf :
password = le mot de passe en clair restricted(pensez à mettre ce fichier en lecture seule pour le super-utilisateur et aucun droit pour les autres !)
Le boot normal de chaque image se passe sans problème et sans demander le mot de passe (important si l'on veut que la machine redémarre seule en cas de pépin : EDF, reboot à distance, ...) mais si l'on veut passer des paramètres au noyau lors du boot, lilo demande alors le mot de passe.
Linux vous permet de travailler en même temps sur plusieurs
fenêtres textes. Pour passer de l'une à l'autre, fais Alt + Fn ou
n est le numéro de la fenêtre virtuelle et Fn une touche
de fonction (par exemple F1, F2 ...). Vous pouvez configurer le nombre de
fenêtres dans le fichier /etc/inittab.
Quand vous êtes sous X, la combinaison devient Ctrl + Alt + Fn. Il est alors possible de retourner sous X en accédant ainsi à la console qu'il emploie (la première "libre", c'est-à-dire non gérée par un getty).
Utiliser maj + pages (touches "SHIFT" et "page précédente" ou
"page suivante") pour "remonter". Ceci fonctionne aussi sous xterm.
Les consoles virtuelles sont des périphériques. Elles sont au nombre de 63 (ou plus, ou moins, si l'on change ça à la compile du noyau). Elles correspondent aux fichiers "spéciaux" tty1 ... tty63 du répertoire /dev.
Maintenant, pour pouvoir les utiliser, il faut pouvoir attacher un processus à ce terminal. C'est le rôle des utilitaires tels que agetty. Il est d'ailleurs interessant de suivre (à l'aide d'un "top") l'évolution des processus lors du login :
Tout d'abord, agetty (de propriétaire root) vous demande votre login. Dès que vous appuyez sur entrée, agetty lance le programme login (toujours de propriétaire root) et se termine.
Login (attaché à la VC puisqu'héritant de agetty) vous demande votre mot de passe. Il lance alors votre shell de login (de propriétaire "vous").
Vous pouvez noter que quand vous terminez votre session (i.e. votre shell de login), un agetty est relancé.
C'est là qu'intervient le fichier inittab. Init (de PID 1),
comme vous le savez est le processus ancêtre de tous vos processus.
Comme c'est le premier processus, c'est lui qui se charge de lancer
les agetty. Il se sert pour cela du fichier de configuration
/etc/inittab.
Entre autres choses, ce fichier contient des lignes du type :
c1:1235:respawn:/sbin/agetty 38400 tty1 linux
Pour une explication, se référer à la page de man d'inittab(5). Ca veut dire en gros qu'init lance un agetty sur /dev/tty1 qu'il relance chaque fois qu'il meurt (respawn) avec un type de terminal Linux pour les cas où on est dans les "runlevels" 1,2,3 ou 5.
Donc, il faut mettre une ligne de ce type pour chaque console virtuelle.
On voit ici qu'il y a autant de agetty de lancés que de consoles virtuelles utilisables, et qu'on est limité par ce nombre des lignes dans inittab (sauf si l'on lance 63 agetty...).
Il existe une autre méthode, c'est l'allocation de VC dynamiquement. Cela se fait grâce à un petit démon (cspawnd)
ftp://ftp.lip6.fr/pub/linux/sunsite/utils/console/dynamic-vc-1.1.tar.gz
cspawnd is normally started in rc.local as a daemon that is signaled by the kernel when the console user presses the Spawn_Console key (see below). Upon receipt of a signal from the kernel, cspawnd activates the newly allocated VC and spawns a getty process to enable the user to login. In its default configuration, it also attempts to periodically deallocate unused VCs.
Il convient alors de laisser une VC gérée par la première méthode, les autres étant alouées dynamiquement.
Maintenant, il faut pouvoir passer d'une VC à l'autre. C'est le noyau qui s'en charge. Quand une touche "ConsoleN" (N=1...63) est frappée, Le noyau fait correspondre la VC numéro N à la console (la vrai).
Il y a aussi "Decr_Console", "Incr_Console" qui respectivement, incrémente et décrémente le numéro de la console ; ainsi que Last_Console qui fait passer à la sernière console utilisée. Cspawnd rajoute la touche "Spawn_Console" (voir plus haut).
Il ne reste plus qu'a faire correspondre ceci a des touches (ou
des combinaisons de touches) du clavier. Cela est fait grâce à
l'utilitaire loadkeys (lancé par init au boot /usr/lib/kbd/keytables/fr-lat1.map pour vous) qui
contient des lignes du style :
keycode 87 = F11 F11 Console_23
control keycode 87 = F11
alt keycode 87 = Console_11
control alt keycode 87 = Console_11
Bien sûr, vous pouvez retrouver tout ceci dans les pages de man et
toutes les aides en ligne mises à votre disposition. Citons
loadkeys(8), init(8), inittab(5), cspawnd(8) ainsi que les fichiers
du répertoire /usr/src/linux/Documentation.
Les "locales" sont un système permettant de gérer le plus proprement possible les différences de langue et de style des utilisateurs. Par exemple, des francophones préfèrent écrire 3,14 plutôt que 3.14, ne notent pas les dates comme les Australiens (qui ne le font pas comme les États-Uniens), etc. Chaque utilisateur doit donc pouvoir choisir une locale qui lui convienne et les applications bien faites (rares sont celles qui gèrent complètement les locales mais nombreuses sont celles qui les utilisent au moins un peu) s'adaptent sans recompilation. En somme, il s'agit de mettre les préférences nationales en dehors de l'application, comme avec le système de ressources du Machinetoc.
Si vous êtes programmeur, vous pouvez consulter le locale-tutorial
(distributions/jurix/source/libc/nls ou
sunsite/utils/nls) ou le
Mini-HOWTO sur les Locales. Si vous êtes simple utilisateur, vous pouvez
connaitre les locales installées sur votre système avec locale -a (les
noms semblent peu standardisés, vous aurez des chaînes du genre "fr_FR" ou
"fr_FR.ISO8859-1") et en sélectionner une avec les variables
d'environnement comme LANG ou LC_CTYPE (man locale donnera peut-être
quelque chose).
Si vous êtes administrateur d'une machine, que les locales ne marchent pas comme vous le souhaitez, lisez le Mini-HOWTO sur les Locales et/ou ce modeste texte.
Si votre Linux n'est pas venu avec une installation correcte des locales (je ne crois pas qu'il existe une bonne distribution de ce point de vue), vous avez deux solutions. Je n'ai testé que la première et elle ne semble marcher qu'avec un noyau supérieur ou égal à 2.0 et une libc version 5.2.18 ou supérieure.
Première solution : compiler les programmes de la libc et utiliser le paquetage WG15-collection.
Pour cela, vous devez récupérer les sources de la libc. Il n'est pas nécessaire de la compiler en entier, juste les programmes de gestion des locales, qui permettent notamment de produire un fichier binaire à partir du source d'une locale. Pour résumer l'installation :
Récupérer libc (ici 5.2.18), par exemple dans
ftp://ftp.lip6.fr/pub/linux/GCC.
(passer root) cd /usr/src mkdir libc-5.2.18 chown <USERNAME> libc-5.2.18 (quitter root) cd libc-5.2.18 tar -xzvf /usr/tmp/libc-5.2.18.tar.gz cd include ln -s /usr/src/linux/include/asm . ln -s /usr/src/linux/include/linux . cd ../libc
Et là vous pouvez lire les instructions dans le README et faire "./configure" ("make depend" est long et ne semble pas nécessaire si vous voulez juste les locales)
Si vous ne voulez pas compiler toute la libc, arrêtez-vous là et :
cd locale make SHARED= programs (passer root) mv localedef /usr/local/bin mv locale /usr/local/bin (quitter root)
Vous avez alors les deux programmes importants. Vous pouvez maintenant générer des locales binaires à partir des sources.
Une bonne collection de sources se trouve dans le fichier
WG15-collection.linux.tar.gz qu'on trouve par exemple en
ftp://ftp.lip6.fr/pub/linux/GCC
(il doit son nom à un "working group" Posix).
Dans ce fichier, une fois détaré, il y a une bonne documentation (Intro). Si vous ne voulez pas la lire, ce qu'il faut faire est :
(passer root) cd charmaps mkdirhier /usr/share/nls/charmap cp ISO_* /usr/share/nls/charmap cd ../locales mkdirhier /usr/share/nls/locale cp POSIX ??_* /usr/share/nls/locale mkdirhier /usr/share/locale (la ligne suivante est a cause de ce qui semble etre une bogue dans la distribution) localedef -c -i /usr/share/nls/locale/en_DK -f ISO_8859-1:1987 en_DK (plein de message d'erreurs du genre "item `yesstr' of category `LC_MESSAGES' undefined" a ignorer) localedef -c -i /usr/share/nls/locale/fr_FR -f ISO_8859-1:1987 fr_FR (quitter root)
Vous pouvez tester avec locale -a que la nouvelle locale est désormais
connue. C'est tout. Les utilisateurs peuvent désormais utiliser les
variables d'environnement des locales comme LANG ou LC_CTYPE.
Deuxième méthode, que je n'ai pas réussi à faire fonctionner :
Récupérer nslutils (aujourd'hui nlsutils-0.5.tar.gz)
par exemple (il semble nécessaire de récupérer des fichiers d'en-têtes comme
localeinfo.h dans la libc).
make make install
Pour tester votre installation des locales, vous pouvez vous servir de Perl 5.003 (c'est la première version de Perl qui teste que l'installation est correcte et produit un message d'erreur autrement) ou ce programme :
#include <stdio.h>
#include <ctype.h>
#include <string.h>
#include <locale.h>
#include <sys/types.h>
#define STRING "beto\b"
void main ()
{
int i;
u_char c;
printf ("Setting locale: %s\n", setlocale(LC_ALL, ""));
for (i=0; i<strlen(STRING); i++) {
c = STRING[i];
printf ("%c (%d) is %s\n",
c, (int)c, isprint((int)c)?"printable":"non-printable");
}
}
Il ne doit pas afficher Setting locale: (null) et, avec la bonne locale française, doit trouver que tous les caractères, sauf le dernier, sont "printables".
Certains outils GNU commencent à être francisés. Pour avoir cette
possibilité, ajoutez dans votre .bashrc les lignes suivantes :
export LC_CTYPE=ISO-8859-1 export LANG=fr
ispell est un correcteur orthographique, en français. Vous pouvez
le récupérer sur ftp.lip6.fr dans /pub/ispell. Il est
également possible de récupérer un dictionnaire français pour
ispell sur le même site dans le répertoire
/pub/ispell/francais.
Ajoutez dans le fichier .inputrc les lignes suivantes :
set meta-flag on set convert-meta off set output-meta on
Il est très désagréable de ne pas avoir les accents lorsque l'on fait un less ou un more d'un fichier. Pour que ce problème ne se pose pas, rajouter :
export LESSCHARSET=latin1dans le fichier
/etc/profile.
less permet aussi d'examiner le contenu de divers types de fichiers
(less toto.tar.gz ...) :
export LESSOPEN="|lesspipe.sh %s"
Placer le script suivant dans un répertoire dont le nom figure dans le PATH :
#!/bin/sh
lesspipe() {
case "$1" in
*.tar) tar tvvf $1 2>/dev/null ;; # View contents of .tar and .tgz files
*.tgz) tar tzvvf $1 2>/dev/null ;;
*.tar.gz) tar tzvvf $1 2>/dev/null ;;
*.tar.Z) tar tzvvf $1 2>/dev/null ;;
*.tar.z) tar tzvvf $1 2>/dev/null ;;
*.Z) gzip -dc $1 2>/dev/null ;; # View compressed files correctly
*.z) gzip -dc $1 2>/dev/null ;;
*.gz) gzip -dc $1 2>/dev/null ;;
*.zip) unzip -l $1 2>/dev/null ;;
*.lha) lha -v $1 2>/dev/null ;;
*.arj) arj l $1 2>/dev/null ;;
*.1|*.2|*.3|*.4|*.5|*.6|*.7|*.8|*.9|*.n|*.man) FILE=`file -L $1` ; # groff src
FILE=`echo $FILE | cut -d ' ' -f 2`
if [ "$FILE" = "troff" ]; then
groff -s -p -t -e -Tascii -mandoc $1
fi ;;
esac
}
lesspipe $1
Pour gs et xdvi, il faut utiliser des options spéciales (sur ma machine, ce sont des alias). En effet, ils sont souvent configurés pour un papier de taille anglo-saxonne.
Ces options sont les suivantes :
gs -sPAPERSIZE=a4 xdvi -paper a4 ghostview -a4
Pour que dvips convertisse les documents dans un format
papier a4, il faut spécifier dans le fichier config.ps
(le chemin varie en fonction des versions de LaTeX) :
@ a4 210mm 297mm @+ ! %%DocumentPaperSizes: a4 @+ %%PaperSize: a4 @+ %%BeginPaperSize: a4 @+ a4
Pour que votre courrier soit en 8 bits (avec accents) sans avoir
besoin de l'encapsuler via MIME ou autre, ajoutez ces trois lignes dans
votre fichier ~/.elm/elmrc :
charset = iso-8859-1 displaycharset = iso-8859-1 textencoding = 8bit
Il peut arriver que lors d'une connexion distante via telnet,
les accents ne passent pas. Dans ce cas, utiliser l'option -L
de telnet.
Certains personnages indélicats se sont permis de bidouiller
les polices de caractères Computer Modern sans en changer le nom ET CE CONTRAIREMENT
A TOUS LES COPYRIGHTS de Knuth. Ceci est EXTREMEMENT grave parce que
tout document typographie avec ces polices de caractères n'aura pas le meme look
qu'avec les VRAIES Computer Modern. Or, malheureusement, ces polices de caractères
fautives ont été livrées sur plusieurs CDs Linux. Comme nous
travaillons quasiment tous avec des CDs slackware, il convient de
faire extremement attention.
C'est pourquoi que vous devriez vérifier votre système. Pour cela, c'est simple, un bon vieux terminal et deux minutes de temps :
**
\setbox0=\hbox{ho}\showbox0
> \box0=
\hbox(6.94444+0.0)x10.55559
.\tenrm h
.\tenrm o
! OK.
<*> \setbox0=\hbox{ho}\showbox0
?
c'est gagné, vous avez les bonnes polices de caractères (la valeur clef à regarder, c'est le 10.55559). Il suffit alors de repondre `x' pour que TeX se termine.
Dans le cas contraire, votre système est vérolé. Il suffit de récupérer les mises à jour et le tour est joué.
Lorsque l'on compile et que l'on se sert d'une carte son sous
Linux, la grande question est de savoir si la carte
est correctement configurée. Pour cela, il existe un fichier
(/dev/sndstat) qui donne toutes les informations sur
la configuration de la carte :
Sound Driver:3.5.4-960630 (Mon Nov 11 14:50:52 MET 1996 root, Linux gandalf 2.0.25 #3 Mon Nov 11 11:44:54 MET 1996 i486) Kernel: Linux gandalf 2.0.25 #3 Mon Nov 11 11:44:54 MET 1996 i486 Config options: 0 Installed drivers: Type 1: OPL-2/OPL-3 FM Type 2: Sound Blaster Type 7: SB MPU-401 Card config: Sound Blaster at 0x260 irq 5 drq 1,5 SB MPU-401 at 0x330 irq 5 drq 0 OPL-2/OPL-3 FM at 0x388 drq 0 Audio devices: 0: Sound Blaster 16 (4.11) Synth devices: 0: Yamaha OPL-3 Midi devices: 0: Sound Blaster 16 Timers: 0: System clock Mixers: 0: Sound Blaster
Pour tester la bonne marche de la carte son, il suffit d'envoyer
quelques fichiers audio (.au) sur /dev/audio, etc.
Certaines version de gcc (2.7.0 à 2.7.2 compris, mais pas 2.7.2.1 et
postérieurs) ont un bug avec l'option -O2. Pour l'identifier,
tester ce programme :
/* sr_bug.c
*
* This program tests for a gcc bug.
* To compile this test program: gcc -O2 sr_bug.c
*
* Sometimes gcc for Intel CPUs generates bad code at optimization
* level 2. The bad code is 'almost right' and stay hidden inside
* a program that seems to work - including the Linux kernel.
* The bug is very old and has been reported. As of 19-Dec-95,
* the bug has not been fixed.
*
* If you change this code you should test it, because even a
* tiny change will hide this elusive bug. If you think you
* fixed the bug, please run the original test just to make
* sure. You can find the original test below, after the #if 0.
* I wrote this version of the test to be user-friendly, and
* it may not be as solid as the original.
*
* Some people who know more than I do:
* davis@space.mit.edu (John E. Davis)
* anlauf@crunch.ikp.physik.th-darmstadt.de (Harald Anlauf)
* craigs@iii2.iii.net (Craig Shrimpton)
*
* User-friendly version by Albert Cahalan
*
*/
#include <stdio.h>
int gcc_sr_bug(void){
static int Array[3]; /* must be static (or global) */
unsigned int B = 3; /* must be unsigned 32-bit */
int i;
for(i=0; i<B; i++) Array[i] = i - 3;
for(i=0; i<B; i++) printf(" %d,%d", i, Array[i]);
return !Array[1];
}
int main(){
printf("Testing for gcc bug...");
if(gcc_sr_bug()){
printf("\n\nBad code! Your compiler generates bad output.\n\n");
printf("Add -fno-strength-reduce to your gcc command line\n");
printf("or put it into your gcc config file, such as in\n");
printf("/usr/lib/gcc-lib/i486-linux/2.7.0/specs.\n");
exit(1);
}else{
printf("\nOK, no problem.\n");
exit(0);
}
}
Emacs est un éditeur de texte très puissant car cohérent et extensible mais consommateur de ressources (processeur et mémoire). La plupart de ceux qui commenceront à l'employer sérieusement, en explorant les documentations, ne pourront bientôt plus s'en passer.
Voici un fichier de configuration de base :
;;
;; Fichier .emacs: initialisation d'emacs
;; Fichier de base : Guide du Rootard
;;
(display-time) ;; Pour avoir l'heure dans la barre d'etat
(setq display-time-24hr-format t) ;; Format 24 heures
;; Nouveaux modes
(autoload 'c++-mode "cplus-md" "C++ Editing Mode" t)
(autoload 'perl-mode "perl-mode" "Perl Editing Mode" t)
(autoload 'c-mode "c-mode" "C Editing Mode" t)
; mieux vaudrait utiliser le "cc-mode"
;; Auto-Mode Settings : positionne le mode selon l'extension
(setq auto-mode-alist
(append '(("\.c$" . c-mode) ;; utilise le mode C++ meme pour C
("\.h$" . c-mode)
("\.C$" . c++-mode)
("\.H$" . c++-mode)
("\.cc$" . c++-mode)
("\.C$" . c++-mode)
("\.pl$" . perl-mode) ;; Perl
("/tmp/snd\.[0-9]*" . text-mode);; Text (pour le mail)
("[Rr][Ee][0-9]*" . text-mode)
("\.ada$" . ada-mode) ;; Ada
("\.spec$" . ada-mode)
("\.body$" . ada-mode)
("makefile$" . makefile-mode) ;; Makefile
("Makefile$" . makefile-mode)
("Imakefile$" . makefile-mode))
auto-mode-alist))
# Remapes varies
(global-set-key "\eg" 'goto-line) ;; ESC G = Goto line
(global-set-key "\eo" 'overwrite-mode)
(put 'eval-expression 'disabled nil)
;; Accents...
(standard-display-european 1)
(load-library "iso-syntax")
;; Sous X-Window, textes en couleurs (C/C++/Shell/Makefile,etc)
(cond (window-system
(setq hilit-mode-enable-list '(not text-mode)
hilit-background-mode 'light
hilit-inhibit-hooks nil
hilit-inhibit-rebinding nil)
(require 'hilit19)
))
(if (not (equal window-system ""))
(global-set-key "\C-?" 'delete-char))
))
;; mieux vaudrait employer font-lock
Ce fichier peut être largement amélioré. Pour en savoir plus, consultee la documentation d'Emacs (appuyer sur "control-H" puis "i"), qui est bien faite mais un peu grosse.
Remarque : il est possible d'ajouter les lignes suivantes pour pouvoir se servir des accents lors de l'édition de fichiers en mode texte :
(set-input-mode (car (current-input-mode))
(nth 1 (current-input-mode))
0)
L'utilisation des ports série pose un problème de verrouillage : il ne faut pas que deux processus concurrents accèdent à un port série donné en même temps. Mais d'autre part, si on a un port série sur lequel tourne un getty pour traiter des appels entrants, on voudrait bien quand même pouvoir utiliser le port série pour passer des appels sortants.
Pour résoudre ce problème, il y a deux approches. La première, c'est le verrouillage par le noyau. Elle utilise deux périphériques différents pour accéder à un port série : /dev/ttySn pour les appels entrant (le getty), et /dev/cuan pour les appels sortant. Quand le getty tente d'ouvrir /dev/ttySn, il est bloqué jusqu'à ce qu'un appel entrant soit reçu et que le modem le signale par la ligne DCD du port série.
Tant que le getty est bloqué dans l'appel système open, on peut encore utiliser le périphérique /dev/cuan pour les appels sortants (évidemment, le getty reste bloqué lorque DCD est activée pour l'appel sortant...)
D'autre part, une fois que /dev/cuan est ouvert, un processus d'une autre session ne peut pas l'ouvrir (si le système est corretement configuré -- voir l'option session_lockout de setserial(8).) Cela évite que deux processus tentant indépendamment de passer un appel sortant se trouvent à écrire simultanément sur le port série.
La seconde technique est celle des "lock-files" (fichiers-verrous). Elle consiste, pour chaque processus qui utilise un port série, à écrire son PID dans un fichier spécial. De cette façon, quand un autre process veut utiliser le même port série, il vérifie la présence de ce fichier, le trouve, lit le PID qui y est écrit, vérifie que le processus correspondant existe, et sait donc que le port série est occupé et qu'il ne peut pas l'utiliser. Dans ce cas, on n'utilise que les /dev/cuan.
Chacune des deux approches a ses avantages et ses inconvénients. La méthode de verrouillage par le noyau nécessite d'employer un modem en mode auto-réponse, et autorise l'ouverture du port série par un processus qui veut passer un appel sortant entre le moment où le téléphone sonne et le moment où les modems on fini de négocier (ce qui peut prendre une dizaine de secondes.) La méthode des lock-files nécessite une configuration homogène des logiciels utilisés (tous les logiciels doivent chercher et mettre le lock-file au même endroit, s'entendre sur le format du PID qui y est inscrit...) Elle nécessite aussi que le getty vérifie périodiquement l'existence du lock-file, et il peut donc "rater" un appel entrant entre le moment où un processus libère le port série et celui où il vérifie à nouveau la présence du lock-file. Il est aussi possible qu'un processus sortant arrive à créer le lock-file entre le moment où le getty détecte un appel et celui où il crée le lock-file pour cet appel.
Le choix d'une méthode est, finalement, une décision individuelle de chaque administrateur, sachant que l'approche "lock-file" est plus souple, mais moins élégante et plus délicate à mettre en oeuvre que le verrouillage par le noyau.
Il est fort agréable de pouvoir se connecter sur le Minitel.
Récupère le programme xtel de Pierre Ficheux. Il s'agit d'un
émulateur Minitel achtement cool à utiliser.
Vous pouvez le trouver sur ftp.lip6.fr dans
le répertoire /pub/X11/videotext/xtel.
Envoyer des documents par FAX est tout à fait possible. Pour cela, utilisez par exemple Hylafax.
Il se trouve sur le site ftp.funet.fi dans le répertoire
/pub/mirrors/sgi.com/sgi/fax/source.
Cette partie s'inspire allégrement de l'article que j'ai écris dans le journal "Les échos de Linux", au mois de Juillet 96.
Le noyau d'un système Unix peut être représenté sous la forme d'un objet monolythique. Toutefois, un tel objet possède l'inconvénient d'être gros et statique. A chaque fois que l'on désire rajouter un nouveau périphérique, il est nécessaire de recompiler le noyau. De plus, si l'on n'utilise certains gestionnaires particuliers que rarement, on est obligé de l'avoir dans le noyau, ce qui a tendance à consommer de la mémoire.
Les modules chargeables, permettent de joindre l'utile à l'agréable en ayant un noyau le plus petit que possible, charge à la demande ce dont il a besoin, d'une manière manuelle par le super utilisateur de la machine, soit d'une manière automatique. De cette manière, le gain de ressources est non négligeable.
La première question que l'on peut se poser, c'est : " Pourquoi deux techniques de chargement ?"
La première technique est manuelle : il faut charger ou décharger les modules à la main. La deuxième est automatique, grâce à l'utilisation d'un démon spécialisé qui est l'esclave du noyau et qui charge et décharge les modules pour lui. En fait, la version 1.2 de Linux n'offrait que la possibilité d'un chargement manuel qui est limité au super-utilisateur de la machine et qui est assez lourd à manipuler. Au fil du développement de la version 2.0, un nouveau système implémenté par Bjorn Ekwall permit d'éffectuer un chargement dynamique et automatique des modules.
Lors de la compilation du noyau, il est nécessaire de spécifier des options particlières pour activer l'utilisation des modules chargeables :
gandalf# make config
*
* Loadable module support
*
Enable loadable module support (CONFIG_MODULES) [Y/n/?]
Set version information on all symbols for modules (CONFIG_MODVERSIONS) [N/y/?]
Kernel daemon support (e.g. autoload of modules) (CONFIG_KERNELD) [Y/n/?]
Voici le détail de ces trois options :
Une fois fois configuré, il vous suffit de lancer la compilation ainsi que l'installation :
gandalf# make dep ; make clean gandalf# make zImage gandalf# make modules ; make modules_install
Une fois ces opérations effectuées, les modules se trouvent alors dans le répertoire /lib/modules/x.y.z où x.y.z correspond au numéro de version du noyau. Il ne nous reste plus à voir que le chargement.
Note importante : tous les outils de manipulation des modules sont
archivés dans un fichier modules-2.0.0.tar.gz dans le répertoire
v2.0. Ils sont installés par défaut avec les distributions standards,
mais il est important d'utiliser la bonne version.
Le chargement manuel est basé sur trois commandes :
insmod : insère un module dans le noyau ;rmmod : décharge un module, s'il plus aucun processus ne
l'utilise ;lsmod : affiche la liste des modules chargés.Leur utilisation oblige d'être en super-utilisateur. Voici un exemple d'utilisation :
gandalf# insmod nfs.o gandalf# lsmod Module: #pages: Used by: nfs 12 4 gandalf# mount -t nfs /truc /mnt gandalf# lsmod Module: #pages: Used by: nfs 12 5 gandalf# cd /mnt ... gandalf# cd / gandalf# umount /mnt Module: #pages: Used by: nfs 12 4 gandalf# ps axu | grep nfs root 5535 0.0 0.0 0 0 q2 SW 17:15 0:00 (nfsiod) root 5536 0.0 0.0 0 0 q2 SW 17:15 0:00 (nfsiod) root 5537 0.0 0.0 0 0 q2 SW 17:15 0:00 (nfsiod) root 5538 0.0 0.0 0 0 q2 SW 17:15 0:00 (nfsiod) root 5557 0.0 0.4 864 300 q2 S 17:16 0:00 grep nfs gandalf# kill -9 5535 5536 5537 5538 gandalf# lsmod gandalf# rmmod nfs.o
Il est nécessaire de "killer" les 4 démons nfsiod car ils sont lancés dès que NFS est activé. Comme vous pouvez le voir, ces opérations deviennent relativement pénibles. C'est pour cette raison que le système de chargement automatique a été crée.
kerneld Le système de chargement automatique de modules permet de réduire au minimum la taille de son noyau. Le principe de fonctionnement est particulièrement simple : un démon en mode utilisateur est à l'écoute des ordres du noyau (via une file de message de type IPC Système V). Lorsque un processus essaye d'accéder à une ressource système (via un appel système open, etc...), le noyau envoie l'ordre de chargement du module à kerneld. Une fois le message reçu, kerneld exécute un modprobe pour charger les modules nécesaires : Schémas du chargement/déchargement des modules avec kerneld
Par contre, lors de la compilation du noyau, il est nécessaire d'y mettre au moins le support pour permettre l'amoçage de la machine et le montage de la racine de votre système de fichiers (par exemple, support IDE + ext2fs). Vous pouvez y mettre tout le reste en module (carte son, systèmes de fichiers, carte SCSI, etc).
Cette partie de modification n'est valable qui si la machine
n'était pas pourvue de kerneld. Les nouvelles distributions
effectuent une installation tout à fait correcte.
Pour réaliser la mise en place du système de chargement de modules, il
est nécessaire d'effectuer certaines modifications au niveau de ta
configuration. En effet, il est nécessaire lors de l'amorçage de la
machine de lancer le démon kerneld et de réaliser une espèce de liste
des dépendances des modules : certains modules ne peuvent être lancés
avant que d'autres ne le soient. Dans un premier temps, il faut créer
le fichier /etc/rc.d/rc.modules dans lequel, mettre :
# Modules
#
# Création d'un lien logique pour le noyau courant
#
#
/bin/rm -f /lib/modules/current
ln -sf /lib/modules/`uname -r` /lib/modules/current
#
# Création des dépendances
if [ \! -r /lib/modules/current/modules.dep ]
then
echo "Creating module dependencies"
/sbin/depmod -a
fi
#
# Chargement des modules d'amorçage...
#
if [ -x /sbin/kerneld ]
then
if find /lib/modules/boot -type f -o type l > /dev/null 2>&1
then
echo "Loading boot-time modules"
/sbin/modprobe -a -t boot \*
fi
else
echo "Loading modules"
/sbin/modprobe -a \*
fi
#
# Si vous possédez d'autres types de démons kerneld à lancer...
#
if [ -x /sbin/kdsound ]
then
echo "Starting sound daemon"
/sbin/kdsound &
fi
Cela permet de générer la dépendance de vos modules à chaque fois que
amorcez votre machine. Ensuite, dans le fichier /etc/rd.d/rc.S
(peut dépendre de la distribution...), il convient d'ajouter :
# Start update.
/sbin/update &
# *** A AJOUTER ***
# Lancement de kerneld le plus tôt possible, de telle manière
# que les modules de systèmes de fichiers puissent être chargés
if [ -x /sbin/kerneld ]
then
echo "kerneld running"
/sbin/kerneld
fi
...
# Un peu de ménage
cat /dev/null > /var/adm/utmp
# Lancement du script des modules
if [ -f /etc/rc.d/rc.modules ]; then
/etc/rc.d/rc.modules
fi
Une fois ces modifications effectuées et la machine réamorcée, tout
doit être en place. Si kerneld permet de charger automatiquement les
modules, il permet également de les décharger au bout d'un certain
temps de nom utilisation. Par défaut, si aucun processus n'accède au
module pendant plus de 60 secondes, il est automatiquement déchargé.
Il est possible de modifier cette valeur en rajoutant le paramètre
delay=Nb_Secondes à kerneld où Nb_Secondes est le délai en nombre de
secondes.
Il peut arriver qu'il soit nécessaire de configurer un dernier fichier :
le fichier /etc/conf.modules. Ce fichier contient les chemins où se
trouvent les modules devant être chargés et ensuite des alias pour les
modules. Si vous n'avez pas ce fichier, vous pouvez le créer avec :
gandalf# /sbin/modprobe -c | grep -v '^path' >/etc/conf.modules
Il peut arriver que lors du premier amorçage vous obteniez ce message :
Cannot locate module for net-pf-3 Cannot locate module for net-pf-4 Cannot locate module for net-pf-5
Pas de panique ! Ce message n'est pas méchant et pour ne plus l'avoir,
ajouter dans le fichier /etc/conf.modules :
alias net-pf-3 off alias net-pf-4 off alias net-pf-5 off
Il peut arriver que certains périphérifériques aient besoin de certains paramètres particulier. Consultez le document Kernel HowTo.
Vous pouvez consulter ces références pour plus d'information :
Le programme "Energy Star" lancé à l'initiative de l'EPA ( "Environmental Protection Agency" américain) a pour objet principal de diminuer la consommation éléctrique des systèmes inactifs. Certains matériels peuvent parfois voir leur durée de vie augmentée.
Linux offre la possibilité d'utiliser des équipements conformes. On peut par exemple programmer une touche ou un menu qui, sur un portable, stoppe la rotation des disque, arrête l'écran et ralenti le système.
Le choix des délais d'inactivité avant une suspension est fonction de l'utilisation du système. Noter également que tous les systèmes ne gèrent pas ces fonctionnalités et que tous les systèmes ne se conportent pas de la même façon d'un constructeur à l'autre.
Les informations ci dessous sont données dans l'espoir d'être utiles mais sont données SANS AUCUNE GARANTIE quand au bon fonctionnement de votre système après les avoir suivi. Si votre petite amie vous largue parce que votre disque dur émet des bruits bizzares ou si votre propriétaire vous expluse après que votre écran a mis le feu à votre appartement, vous en avez l'entière responsabilité.
L'arrêt de la rotation du disque dur présente un avantage supplémentaire à ceux énoncés plus haut : celui de rendre le système moins bruyant. Cependant, sur Unix, quelques démons accèdent aux données sans réel besoin et ont tendance à réveiller le disque.
Certains BIOS peuvent suspendre le disque après une non utilisation. Rechercher l'option "HDD Standby Timer". Avec les disques IDE, on peut utiliser l'utilitaire hdparm(8) qui fait la même chose :
$ hdparm -S 120 -- arrete le disque apres 10 minutes (120 x 5s)
$ hdparm -Y -- suspend le disque tout de suite
Si le disque ne veut jamais s'arrêter en mode normal (mais qu'il le fait bien par exemple en mode "single user") ou s'il reprend son activité sans raison apparente, c'est que des programmes continuent à lire et écrire sur le disque sans que vous ne fassiez quoi que ce soit. Ces programmes (démons) sont normalement lancés au boot, le jeu consiste à les détecter et les reparamétrer.
Pour la détection, il faut que vous aillez un moyen de surveillez les accès *physiques* au disque dur, que ce soit au bruit d'un accès ou une led d'activité. Ensuite, voici trois méthodes pour rechercher les agitateurs :
strace -p sur les numéros de processus des démons
suspects. Si vous voyez une activité disque en même temps qu'une
activité du processus, vous tenez probablement là un des coupables.
strace(1) vous indique également quels fichiers sont accédés et la
périodicité des accès.top
Ces champs ne sont pas présents par défaut mais vous pouvez les
insérer (appuyez sur "o"). Le champs "timeout" indique le temps qu'il
reste avant qu'un appel à seclect(2) ne termine. Si vous le voyez
passer à 0 sur un processus pendant un accès disque physique, vous
tenez un des coupables. Le champs "alarm" est moins utile, il
représente la durée en secondes entrée comme argument à la fonction
alarm(2) on peut mettre ces valeurs en corrélation avec une éventuelle
périodicité des accès physiques.Voici une liste de démons ayant un comportement périodique susceptible de réveiller le disque.
Le démon cron(8) lance des programmes à certaines heures. Il n'est
pas directement en cause dans les accès disques (il ne fait que des
accès en lecture pour vérifier que ses tables n'ont pas changé mais
ces information sont la plupart du temps dans le cache disque)
Certaines distributions insèrent dans la crontab(5) des processus
lancés toutes les quelques minutes. Jetez un coup d'oeil dans les
crontabs des utilisateurs démons (root, news, uucp...) ou dans le
fichier /etc/crontab et faîtes le ménage.
Dans certaines distributions, le programme "atrun" est lancé toutes les minutes. Il sert à exécuter des programmes à une date donnée avec la commande "at". Si vous ne vous en servez pas, désactivez le sinon essayez le démon "atd" du package "at-3.1.*"
Conservez les lignes qui nettoient les logs et rassemblez les autour d'une même heure.
mgetty vérifie toutes les quelques minutes que le modem répond bien. Comme il note toutes ses actions dans un fichier de log (en fonction du paramètre "debug") cela entraine des accès disques non désirables.
Parade: Mettre une période de vérification démesurément longue dans mgetty.config. Par exemple :
modem-check-time 360000
vérifie toutes les 100 heures. Cette option n'a pas l'air désactivable.
"lpd" vérifie la queue et l'activité des démon toutes quelques dizaines de minutes.
Parade : désactivez cette option dans /etc/lpd.conf :
poll_time 0
Le serveur maître "httpd" discute avec ses co-serveurs via le fichier log/apache_status.
Parade : lancez httpd via inetd.
De nombreux commentaires déconseillent d'utiliser apache avec inetd pour des raisons de performance (inetd doit forker un serveur qui va relire et analyser sa config à chaque URL demandée) mais si votre serveur n'a pas énormément d'accès, c'est tout à fait jouable.
bind 8.1 (named) logue toutes les heures des information sur ses activités.
Parade: Envoyez ces information ailleurs que sur le disque dur (sur une console, par exemple ou désactivez les carrément. Dans /etc/named.conf :
logging {
category statistics { null; };
category maintenance { null; };
};
Squid fait constamment le ménage dans les fichier cachés.
Parade : aucune avec squid lui même, mais on peut utiliser le module proxy d'apache (voir plus haut). Ce module n'est pas actif dans la configuration par défaut. vous devrez peut-être recompiler apache pour vous en servir.
Sendmail vérifie périodiquement la queue pour réexpédier le courrier qui peut s'y trouver.
Parade : Avez vous vraiment besoin d'un sendmail en démon (c.-à-d. votre machine est elle censée recevoir du courrier par SMTP) ? Si vous pensez que non, tuez le processus et vérifiez que votre lecteur de courrier fonctionne encore (mail, vm, rmail, mush, pine... se passent de démon mais mh en a parait-il besoin). Regardez aussi si vous ne pouvez pas vous servir du démon d'une autre machine.
Si vous avez vraiment besoin de sendmail en démon, lancez le au
boot sans l'option " -q
Les moniteurs suivant la norme VESA DPMS peuvent être mis en veille. Le moniteur passe successivement par plusieurs étapes :
Le paramétrage est différent selon que l'on se trouve sous X ou pas.
La commande "setterm" permet de déterminer si on utilise DPMS et avec quelle durée :
$ setterm -blank 10 # extinction apres 10 minutes (defaut)
$ setterm -powsersave on
On peut faire un réglage plus fin avec les séquences d'échappement:
ESC[9;intervalle] "intervalle" est le nombre de minutes
d'inactivite avant d'entrer en mode "suspend"
ESC[14;intervalle] nombre de minutes d'inactivite entre le mode
"suspend" et le mode "off".
Voir, dans les sources de linux, le fichier drivers/char/vesa_blank.c pour plus de détails.
Dans XFree86 3.3, les défauts sont initialisés dans le fichier XF86Config(4), pour activer le mode DPMS, ajoutez dans le section "Devices"
Option "power_saver"
Ensuite vous pouvez paramétrer les délais StandbyTime, SuspendTime et OffTime de la section "Monitors" comme indiqué dans le manuel.
On peut changer ces valeurs au vol ou passer dans un état particulier avec la commande xset(1)
Les BIOS supportant APM (Advanced Power Management) peuvent faire passer le système par 3 stades d'inactivité :
Lorsque le système est ralenti, Linux perd la notion du temps réel (son horloge est ralentie) Tous les programmes qui effectuent des actions périodiques (en particulier CRON) sont perturbés. L'horloge est remise à l'heure une fois le système reparti si le noyau est compilé pour supporter APM (sinon, remettez la avec "clock").
Si vous comptez faire des gros calculs, utiliser la crontab ou vous si votre machine fait office de serveur, je doute que les options APM vous soient utiles, mais sur un portable c'est sûrement tout autre chose (si quelqu'un m'offre un portable, je lui ferais part de mes impressions.)
L'utilitaire apmd (ftp.cs.unc.edu:/pub/users/faith/linux/apmd-2.4.tar.gz) permet de surveiller les états liés à APM ou forcer la suspension.