Ce document est disponible selon les termes de la Creative Commons Attribution 2.5 License.
Dernière mise à jour et validation le 30 décembre 2017.
La configuration créée par anXious lors de
l'installation ne vaut pas grand chose. XDM est bien lancé
automatiquement, mais l'image est franchement mauvaise. Elle
est mal centrée. Et le pire est une espèce de défilement
vertical de points style scroll d'étoiles de
vieille intro Amiga, sur le fond moiré typique X Window. En plus la souris ne répond
presque pas, c'est-à-dire environ une fois toutes les 5
secondes. Je peux cependant ouvrir une session.
À l'ouverture de la session le message suivant apparaît :
You do not have a ~/.fvwm directory present! The Debian version of FVWM uses hook files for customisation; please see /usr/share/doc/fvwm/README for more details. (Creation of a ~/.fvwm directory or touching ~/.fvwm.nowarn will disable this warning)
Problème un, rendre XFree86 utilisable. FVWM peut attendre. Je vais
ressayer anXious. Mais d'abord il faudrait tuer
XFree86 par prudence. man XFree86 me
rappelle la combinaison : Ctrl-Alt-backspace.
Zut, XDM est automatiquement relancé. Tant pis, on verra,
lançons anXious.
anXious ne fait rien. Sans doute
car XFree86 tourne, bien que je le lance depuis une console
en mode texte. En revanche xviddetect
(j'ai appris son existence dans le manuel de
anXious) m'apprend que le serveur pour ma
Matrox
est effectivement svga. C'est déjà
une erreur que je n'ai pas faite.
Faute d'anXious, je décide de remplacer le
fichier /etc/X11/XF86Config
qu'il avait construit par celui que j'utilisais sur Red
Hat avec un serveur XFree86 à peine plus ancien. Je
redémarre XFree86, et boum, ou plutôt tactactactactac fait
mon écran en se synchronisant sans rien afficher. Finalement
écran noir, XFree86 s'est complètement arrêté. Plus de trace
avec ps x sous
root.
Ce qui est bien, c'est que je peux lancer
startx et enregistrer le résultat (startx 2>
startx_redhat.txt). C'est un problème de
souris. En fait /dev/mouse n'existe plus sur
Debian.
Mais XFree86 étant arrêté, je peux en profiter pour bien
faire les choses avec anXious. Il me
demande à nouveau toute la configuration, XDM, les
gestionnaires de fenêtres, etc. C'est
emm^H^Hnnuyant mais j'en profite pour entrer les
bonnes valeurs : 30-95 KHz pour les
fréquences horizontales de l'écran ;
50-150 Hz pour les fréquences verticales. Et
puis je sélectionne TI 3026 comme clockchip
(je n'avais pas encore lu /usr/share/doc/xserver-common/README.MGA.gz).
Une fois anXious terminé, il m'indique de lancer
apt-get dselect-upgrade. Mais il n'y
a aucun paquet à changer.
Je relance startx 2>
startx_anXious_2.txt, mais l'affichage est
toujours aussi pourri. Je suis aussi étonné de voir la même
erreur bénigne que sur Red
Hat : System: `/usr/X11R6/lib/X11/xkb/xkbcomp
-w 1 -R/usr/X11R6/lib/X11/xkb -xkm -m fr_CH -em1 "The
XKEYBOARD keymap compiler (xkbcomp) reports:" -emp "> "
-eml "Errors from xkbcomp are not fatal to the X server"
keymap/xfree86 compiled/xfree86.xkm'.
Je crois qu'anXious n'a définitivement pas sa
place dans une distribution stable. Je laisse donc son XF86Config.
Je reprends le
XF86Config de ma Red Hat et je change
/dev/mouse en /dev/ttyS1. Ce
fichier demande sûrement un peu de ménage, mais en attendant,
il va très bien. J'ai retrouvé mon 1280×1024 en 24 bits avec
une souris qui fonctionne. Je remarque aussi
qu'anXious ne m'avait pas proposé le protocole
MouseMan, pas étonnant si la souris répondait
mal.
À présent que XFree86 fonctionne, je peux noter toutes mes petites observations dans Journebian. :-) Reste à voir s'il sera possible de mettre tout cela en ligne…
Au moment où j'écris cette ligne, je n'ai aucune idée du
moyen prévu par Debian
pour se connecter à Internet par PPP. Mais je sais deux
choses : j'ai configuré un programme wvdial
durant l'installation et la documentation d'installation a un
chapitre sur PPP.
Je ne peux pas utiliser wvdial en
tant qu'utilisateur marc car le fichier /etc/wvdial.conf
appartient à root:dialout. Il faudrait que
j'ajoute marc au groupe dialout.
Mais puis-je simplement éditer /etc/group ou dois-je
utiliser une méthode particulière sur Debian (pour des
questions d'intégrité de fichier, de signature, shadow
passwords ou que sais-je) ? À voir plus tard.
Je lance wvdial en tant que
root. Petit problème, pas de tonalité. Pourtant
j'entends bien le modem décrocher. Je suspecte une des
commandes AT bizarres de wvdial.
ATQ0 V1 E1 S0=0 &C1 &D2 S11=55
+FCLASS=0, c'est quoi ce
+FCLASS=0 ? Je vais remplacer
ça par un réglage plus simple qui a fait ses preuves :
ATZ. Marche pas non plus.
C'était la ligne téléphonique qui avait un problème. Je
deviens trop soupçonneux. Wow, PPP est directement lancé sans
autre réglage ! ping reçoit bien des échos,
toujours aussi irréguliers que sur Red Hat :
64 bytes from 194.230.3.183: icmp_seq=28 ttl=255 time=120.0 ms 64 bytes from 194.230.3.183: icmp_seq=29 ttl=255 time=120.1 ms 64 bytes from 194.230.3.183: icmp_seq=30 ttl=255 time=2240.1 ms 64 bytes from 194.230.3.183: icmp_seq=31 ttl=255 time=1780.0 ms 64 bytes from 194.230.3.183: icmp_seq=32 ttl=255 time=790.0 ms 64 bytes from 194.230.3.183: icmp_seq=33 ttl=255 time=120.0 ms 64 bytes from 194.230.3.183: icmp_seq=34 ttl=255 time=680.0 ms 64 bytes from 194.230.3.183: icmp_seq=35 ttl=255 time=24760.0 ms 64 bytes from 194.230.3.183: icmp_seq=36 ttl=255 time=23770.0 ms 64 bytes from 194.230.3.183: icmp_seq=37 ttl=255 time=22780.0 ms
C'est le grand mystère de ma vie. :-) Comment un simple
ping sur l'autre bout de la ligne peut prendre
autant de temps ? (Note : mystère partiellement
résolu le 11 avril 2001.) Et quand
je dis l'autre bout, c'est vraiment tout près :
marc@yok-yok:~$ /sbin/route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
194.230.3.183 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
0.0.0.0 194.230.3.183 0.0.0.0 UG 0 0 0 ppp0
Bon, je vois qu'il faut encore configurer les serveurs de
noms. Le chapitre
7.26 Setting up PPP indique qu'il faut
utiliser un éditeur normal. Je décide de reprendre simplement
le /etc/resolv.conf
que j'avais sur Red Hat :
search
nameserver 194.158.230.53
nameserver 194.158.230.54
Je ne suis pas sûr que le search seul sur sa
ligne soit réellement utile.
Je constate (/sbin/pppstat -w 1 et
netstat --ip sont mes amis) que
LeafNode est
lancé automatiquement. Évidemment il me mange toute la bande
passante. Au lieu de LeafNode, j'aimerais bien disposer d'un
autre navigateur que Lynx.
dselectD'abord j'aimerais comprendre à quoi correspond le fourbi
que l'installation a créé dans /cdrom :
marc@yok-yok:~$ ls -l /cdrom/
total 0
lrwxrwxrwx 1 root root 6 Jan 27 19:00 cdrom -> /cdrom
lrwxrwxrwx 1 root root 9 Jan 27 19:01 scd0 -> /dev/scd0
Un lien récursif, ce n'est pas très malin. M'étonne pas que Apt ait eu du mal à monter automatiquement les CD-ROM. En revanche je suis étonné de pouvoir monter par-dessus un répertoire non vide.
J'ai ajouté quelques combines avec
dselect. En fait il me semble qu'il a
installé bien plus que je n'ai sélectionné. Je suppose qu'il
s'agit d'oublis de l'installation. Il faudra que je lise
attentivement les manuels pour trouver comment afficher la
liste des paquets installés et installables.
Parmi mes ajouts sélectionnés, il y a Mozilla (excellente raison de
laisser tomber la Read
Hat 5.2), puis ImageMagick et
nslookup.
En revanche pas de Netscape 4.
Il y a bien des paquets netscape-4-base, mais je
ne vois pas Communicator. C'est bizarre. Est-il sur le
CD-ROM ? Je ne le trouve pas. Ce n'est pas que je tienne
tellement à ce programme, mais j'aimerais bien récupérer mes
archives de courrier. Or Mozilla M18 n'en semble pas capable.
D'ailleurs je préférerais nettement Mozilla 0.7 à M18 ;
encore un truc à mettre à jour.
Aujourd'hui il s'agit de trouver les paquets de
Communicator et d'installer tous les patchs de sécurité. Dans
le vain espoir de trouver plus de paquets, je commence par
éditer /etc/apt/sources.list
en ajoutant non-free dans la liste des
paramètres de chaque CD-ROM :
deb cdrom:[Debian GNU/Linux 2.2 r2 _Potato_ - Official i386 Binary-3 (20001207)]/ unstable contrib main non-US/contrib non-US/main non-free
deb cdrom:[Debian GNU/Linux 2.2 r2 _Potato_ - Official i386 Binary-2 (20001207)]/ unstable contrib main non-US/contrib non-US/main non-free
deb cdrom:[Debian GNU/Linux 2.2 r2 _Potato_ - Official i386 Binary-1 (20001207)]/ unstable contrib main non-US/contrib non-US/main non-free
Ensuite j'apprends dans la douleur que je ne peux pas
directement utiliser dselect pour
mettre à jour la liste des paquets. Je dois passer par un
apt-cdrom -m add pour chaque CD-ROM
(le -m c'est à cause du fourbi avec
/cdrom). Mais en
fait les trois lignes précédentes avaient été écrites par
apt-cdrom qui indique exactement ce qu'il y a
sur chaque CD-ROM. Mon /etc/apt/sources.list
est donc remis dans l'état original par
apt-cdrom.
Dans ce cas j'ajoute les lignes conseillées par la documentation envoyée avec les CD-ROM :
deb http://security.debian.org/debian-security potato/updates main contrib non-free
deb http://http.us.debian.org/debian potato main contrib non-free
deb http://non-us.debian.org/debian-non-US potato/non-US main contrib non-free
Ensuite je n'ai plus qu'à lancer apt-get update
&& apt-get -u dist-upgrade comme écrit
dans la documentation. Et lire le manuel pendant les
téléchargements pour savoir ce que je suis en train de faire.
:-)
Je suis soufflé par la résistance de wvdial
et Apt aux conditions lamentables de ma liaison PPP. La
connexion est régulièrement perdue, mais wvdial
le détecte, arrête PPP, raccroche le modem et retente
automatiquement une connexion. Apt génère quelques kilomètres
de messages d'erreur, mais ne s'arrête pas.
Aujourd'hui je dois urgemment installer l'imprimante pour des raisons indépendantes de ma volonté. Ce n'est pas vraiment évident de trouver de la documentation Debian sur le sujet. The Linux Printing HOWTO donne pas mal de pistes et conseille Apsfilter. Peut-être suffit-il d'installer quelque-chose comme Apsfilter pour que la configurations soit automatiquement lancée ?
Il y a effectivement un script pour installer Apsfilter.
Il y a aussi un petit supplément à la GPL : l'auteur
aimerait recevoir une carte postale de ma part. Je peux
demander son adresse à request-snailmail@klemm.gtn.com.
Il me manque quelques filtres (djpeg,
g3cat, html2ps,
pnmtolps, ras2ps et
recode). Rien de grave, je pense que le
principal est que gs soit là.
Le script d'installation d'Apsfilter est vraiment bien, ça
semble largement mériter une carte postale ! J'hésite
tout de même sur le pilote d'imprimante pour ma Xerox DocuPrint P8e (compatible
PCL5e). Sur Red Hat j'avais ljet4, soyons
conservateur, mais après avoir tout essayé. :-)
Bien, j'ai un /etc/printcap tout
neuf à la syntaxe cryptique à souhait. J'ai aussi plein de
répertoires dans /var/spool/lpd/ des
fois que je veuille me reconvertir en imprimeur. Je peux même
configurer toutes sortes de filtres (genre
recode au lieu de a2ps). Mais je ne
suis pas convaincu que mes six impressions par année vaillent
cette peine…
Je vais cependant installer Lyx, ça me fera une introduction à Latex, et peut-être que ça ressemblera suffisament à Word pour convaincre ma compagne.
J'hésite entre SUDO et SUID plus groupes bien choisis pour
donner aux utilisateurs normaux le droit d'éteindre
l'ordinateur ou de lancer PPP. Pour l'instant j'ai repris le
/etc/sudoers
de que j'avais fait pour Red Hat. C'est un avantage de SUDO,
portable, non intrusif… Mais c'est un peu plus lourd,
par exemple pour autoriser des options de
shutdown.
J'ai reçu quelques réponses de linux-leman@alphanet.ch
mais rien de décisif. Mais en fait je vais utiliser SUDO
car :
/etc/sudoers ;Voici à quoi ressemble mon /etc/sudoers :
# User alias specification
User_Alias LOCAUX=user1,user2
# User privilege specification
root ALL=(ALL) ALL
LOCAUX ALL=(root) NOPASSWD: /sbin/shutdown -[hr] now
LOCAUX ALL=(root) NOPASSWD: /usr/bin/wvdial
.bash_profile &
.bashrcJ'essaie de comprendre la philosophie derrière les
.bash_profile et .bashrc par défaut
de Debian.
.bash_profile est notamment conçu pour être
appelé par chaque shell interactif. Par exemple
il peut ajouter ~/bin à $PATH. Mais
les xterm ne lancent pas le shell en mode
login. Donc .bash_profile est
virtuellement inutile pour les utilisateurs de X Window.
J'hésite entre faire en sorte que xterm lance
le shell en mode login, solution qui semble
propre, mais qui doit être répétée pour chaque terminal, ou
appeler .bashrc depuis
.bash_profile et ne pas différencier les shells
login des autres. Cette solution me paraît plus
fiable.
Grâce aux explication de Marc Schaefer, je crois que je
commence à avoir une vue d'ensemble sur les questions
relatives à .bash_profile et
.bashrc. Voici un passage éclairant de notre
dernier échange de courrier :
> Mais existe-t-il une raison logique pour laquelle le shell n'est > pas lancé en mode login par les xterm ? Cela semble illogique Si, car souvent en mode login tu as le /etc/motd affiché, le test de mail, etc. Et à chaque xterm ça serait fatigant. Mais bon, tout cela est fonction de conventions: de plus en plus de ce qui précède est fait par le programme login ou sshd.
Il n'est effectivement pas logique que les
xterm lancent le shell en mode
login. Après tout le login se fait dans XDM. Je
vais donc lire la documentation de XDM. Et avec un peu de
chance je pourrai configurer XDM pour qu'il affiche /etc/motd. Pour le
courrier, n'utilisant que le courrier avec Internet par
POP3/SMTP, je peux m'en passer.
D'un autre côté, un message de Daniel Cordey m'apprend que je peux configurer tous les terminaux X Window d'un seul coup :
> Faudrait-il toujours lancer xterm -ls ? Pour autant que je sache, tous les *terms ont une option pour lancer leur *profile. Pour eviter de modifier les options de lancement des *term dans vos environement, vous pouvez aussi specifier cette 'ressource' X11 dans app-defaults, ou autre fichiers que vous utilisez (.Xdefaults, etc.)
Je vois dans la documentation de login, qu'il
se charge d'afficher /etc/motd, de vérifier le
courrier et d'initialiser quelques variables d'environnement
intéressantes ($HOME, $SHELL,
$PATH, $LOGNAME, $MAIL
et peut-être $TERM). D'ailleurs on peut voir pas
mal de ces variables - et d'autres - dans /etc/login.defs.
L'équivalent de /etc/login.defs
pour XDM semble être /etc/X11/xdm/xdm-config.
Mais la documentation de
XDM est impressionnante (1584 lignes) et ce n'est de loin
pas le seul fichier de configuration. Je ferais bien de
comprendre le fonctionnement de cette configuration avant de
me lancer dans des modifications.
J'ai remarqué que toutes sortes de démons étaient lancés
par défaut, comme statd, lockd ou
wwwoffled. En plus /etc/inetd.conf
semble contenir des entrées peu sures :
#:STANDARD: These are standard services.
telnet stream tcp nowait telnetd.telnetd /usr/sbin/tcpd /usr/sbin/in.telnetd
#:BSD: Shell, login, exec and talk are BSD protocols.
talk dgram udp wait nobody.tty /usr/sbin/tcpd /usr/sbin/in.talkd
ntalk dgram udp wait nobody.tty /usr/sbin/tcpd /usr/sbin/in.ntalkd
#:MAIL: Mail, news and uucp services.
nntp stream tcp nowait news /usr/sbin/tcpd /usr/sbin/leafnode
#:INFO: Info services
finger stream tcp nowait nobody /usr/sbin/tcpd /usr/sbin/in.fingerd
ident stream tcp wait identd /usr/sbin/identd identd
Bref, il y a du pain sur la planche pour sécuriser et
décharger ce système. Je commence par XFree86. Selon le conseil de
Marc Schaefer, j'interdis au serveur X d'écouter TCP, grâce à l'option
-nolisten tcp. Le serveur X est lancé par
xdm en suivant les indications du fichier
/etc/X11/xdm/Xservers
qu'il faut donc éditer. Il n'y a qu'une ligne non commentée,
c'est assez facile :
:0 local /usr/bin/X11/X vt7 -deferglyphs 16 -nolisten tcp
Il ne s'agit cependant pas exactement de la commande
lancée par xdm. En effet, ps
-x me donne :
/usr/bin/X11/X vt7 -deferglyphs 16 -nolisten tcp
-auth
/var/lib/xdm/authdir/authfiles/A:0-elRNpp
Après avoir empêché XFree86 d'écouter les messages
TCP, je vais empêcher XDM d'écouter les messages XDMCP qui passent
par UDP. Après il
y aura encore beaucoup à faire, comme le montre
netstat -ap --ip :
Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 *:1024 *:* LISTEN 211/xdm tcp 0 0 *:5865 *:* LISTEN 200/junkbuster tcp 0 0 *:tproxy *:* LISTEN 193/wwwoffled tcp 0 0 *:webcache *:* LISTEN 193/wwwoffled tcp 0 0 *:printer *:* LISTEN 171/lpd tcp 0 0 *:auth *:* LISTEN 165/inetd tcp 0 0 *:finger *:* LISTEN 165/inetd tcp 0 0 *:nntp *:* LISTEN 165/inetd tcp 0 0 *:telnet *:* LISTEN 165/inetd tcp 0 0 *:time *:* LISTEN 165/inetd tcp 0 0 *:daytime *:* LISTEN 165/inetd tcp 0 0 *:discard *:* LISTEN 165/inetd tcp 0 0 *:756 *:* LISTEN 153/rpc.statd tcp 0 0 *:sunrpc *:* LISTEN 90/portmap udp 0 0 *:xdmcp *:* 211/xdm udp 0 0 *:ntalk *:* 165/inetd udp 0 0 *:talk *:* 165/inetd udp 0 0 *:discard *:* 165/inetd udp 0 0 *:754 *:* 153/rpc.statd udp 0 0 *:sunrpc *:* 90/portmap raw 0 0 *:icmp *:* 7 - raw 0 0 *:tcp *:* 7 -
Pour empêcher XDM d'écouter les messages XDMCP,
man xdm indique qu'il faut lui passer
le paramètre -udpPort 0. Une autre solution, qui
a l'air plus en ligne avec la configuration Debian est d'insérer la ligne
DisplayManager.requestPort: 0 dans /etc/X11/xdm/xdm-config.
Il y a un certain nombre de serveurs à désinstaller,
heureusement ça va assez bien avec
dselect :
Removing fingerd ... Removing nfs-server ... Removing nfs-common ... Stopping NFS common utilities: lockd statd. dpkg - warning: while removing nfs-common, directory `/var/lib/nfs' not empty so not removed. Removing pidentd ... Removing talkd ... Removing telnetd ...
J'aimerais encore supprimer LeafNode et peut-être
wwwoffled, mais ils font partie d'un
(méta-?)paquet task-dialup que je n'aimerais pas
détruire ou corrompre.
Je viens d'installer et essayer
cruft et même si c'est clairement une
version alpha, il y a déjà quelques combines pas trop clairs
sur mes disques.
J'ai installé le paquet ntpdate pour ne plus
avoir à régler mon horloge tout en restant à l'heure. La
configuration par dpkg est originale :
You must customize /etc/init.d/ntpdate
before ntpdate can be run. Ayant une connexion
intermittente, selon /usr/share/doc/ntpdate/README.Debian,
je dois lancer ntpdate depuis les scripts de
lancement de PPP. Mais avant cela, il faut que je trouve des
adresses IP de
serveurs de temps.
La recherche de serveurs NTP n'est pas aussi facile que
je le pensais. J'ai mis au moins une demi heure pour trouver
un serveur en Suisse. Peut-être aurais-je dû utiliser un
autre moyen que Google
pour mes recherches ? Enfin, j'ai trouvé une liste à
http://www.eecis.udel.edu/~mills/ntp/clock2.htm.
Il semble que bernina.ethz.ch (129.132.98.11)
soit le seul stratum 2 de Suisse. L'auteur de
ntpdate semble avoir le serveur
louie.udel.edu (128.175.1.3).
Je vais essayer avec ces deux serveurs. Je ne suis pas sûr
que l'horloge matérielle soit réellement réglée par
ntpdate, je verrai. J'aimerais aussi comprendre
pourquoi les adresses IP semblent à la mode pour les serveurs
NTP. Ou plutôt semblaient, car la plupart des serveurs
conseillent d'utiliser le DNS pour trouver leur
adresse.
Pour lancer ntpdate au lancement de PPP
plutôt qu'à l'amorçage du système, je crée un script de
démarrage dans /etc/ppp/ip-up.d/.
Pas besoin de script d'arrêt puisqu'il ne s'agit pas d'un
démon. J'ai cependant dû prendre garde à supprimer l'option
-b du script original /etc/init.d/ntpdate.
Je viens de me connecter. Je suppose que la ligne
Feb 5 01:32:00 yok-yok ntpdate[1207]: step time server
129.132.98.11 offset -13.808933 sec dans /var/log/daemon.log
signifie que je suis à l'heure. Quant à l'horloge matérielle,
elle est mise à jour lors de l'arrêt du système. Cette
distribution est vraiment merveilleuse !
Aujourd'hui j'ai installé The GIMP, de la documentation pour
Xfig et le paquet
gsfonts-x11. Pour ce dernier paquet, ça n'a pas
l'air au point. Maintenant toutes mes polices non fixes sont
affreusement empâtées. J'avais trouvé un si beau réglage pour
Netscape. C'est trop dommage, il faut que je supprime ce
paquet…et voilà, je retrouve mes superbes polices
bitmaps.
J'ai reçu de linux-leman@alphanet.ch
un courrier m'assurant que je pouvais désinstaller
task-dialup sans perdre les sous-paquets. En
fait cela fonctionnerait simplement par dépendances. En
outre, la raison pour laquelle NTP est configuré par adresse
IP plutôt que nom vient du fait qu'il serait souvent démarré
avant le serveur DNS requis. Voilà
une explication logique comme j'aime. Merci Daniel.
Grâce à dpkg -S
/etc/init.d/portmap j'ai aussi découvert que
portmap faisait partie du paquet
netbase, lequel contient plein de programme
nécessaires (dpkg -L netbase). Je
vais donc devoir modifier cette installation. À voir. En
attendant LeafNode me laisse plein de cochonneries :
dpkg - warning: while removing leafnode, directory `/var/spool/news/message.id' not empty so not removed. dpkg - warning: while removing leafnode, directory `/var/spool/news/leaf.node' not empty so not removed. dpkg - warning: while removing leafnode, directory `/var/spool/news' not empty so not removed. dpkg - warning: while removing leafnode, directory `/etc/news/leafnode' not empty so not removed. dpkg - warning: while removing leafnode, directory `/etc/news' not empty so not removed.
Je viens de découvrir l'existence du paquet
debian-policy. Je sens que je vais passer
quelques temps dans /usr/share/doc/debian-policy/
avant de poursuivre mes modifications. Surtout que la
suppression de /var/log/news/ avec
LeafNode n'a pas entraîné les mise à jour nécessaires de
/etc/syslog.conf
À part ça, j'ai bataillé contre les brevets sur les logiciels. J'ai notamment publié mes opinions sur la question.
J'ai supprimé le mot search qui traînait dans
/etc/resolv.conf.
J'ai envoyé un courrier à l'auteur d'Apsfilter pour lui demander
son adresse postale afin de pouvoir lui envoyer une carte.
J'ai compris l'usage de diald. Il faudra que je
le configure à l'occasion. Ça simplifiera bien la vie de
certaine. Je remarque aussi un nombre incroyable de trucs
lancés par cron. Il faudra aussi que j'essaie
d'en comprendre l'utilité.
Enfin je suis très heureux de voir que la configuration du clavier est prise au sérieux par Debian, du moins dans la politique générale. Je l'avais remarqué avec les excellentes compositions de touches par défaut. Mais en plus on peut effacer à gauche ou à droite à peu près partout, sauf dans Emacs sous X. Je ne pourrai pas considérer que mon système est bien configuré tant que je ne pourrai pas effacer à droite avec la touche Delete dans Emacs sous X !
J'ai enfin découvert le répertoire /var/lib/dpkg/info/
et les fichiers *.conffiles. Je sens
que cela va m'aider à configurer plus aggressivement mon
système. Pour l'instant il me semble n'avoir changé que des
fichiers de configuration reconnus, ouf !
Pour supprimer portmap,
François (merci) m'a conseillé update-rc.d -f
portmap remove. Je vais faire de même avec ce
qui reste de ntpdate dans /etc/init.d/. Pour
wwwoffled, en revanche,
Dominique m'a conseillé de l'essayer. Mais avant
d'essayer wwwoffled je commente les références à
/var/log/news/ dans
/etc/syslog.conf.
Voilà, à présent mon système est raisonnablement allégé. Mais il y a encore du travail au niveau des démons, je vois encore :
lpddialdwwwoffledeximxfsxdmCependant netstat -ap --ip me
donne déjà un résultat réjouissant :
Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 *:tproxy *:* LISTEN 470/wwwoffled tcp 0 0 *:webcache *:* LISTEN 470/wwwoffled tcp 0 0 *:5865 *:* LISTEN 191/junkbuster tcp 0 0 *:printer *:* LISTEN 162/lpd tcp 0 0 *:time *:* LISTEN 156/inetd tcp 0 0 *:daytime *:* LISTEN 156/inetd tcp 0 0 *:discard *:* LISTEN 156/inetd udp 0 0 *:discard *:* 156/inetd raw 0 0 *:icmp *:* 7 - raw 0 0 *:tcp *:* 7 -
Je trouve le noyau un peu lent au démarrage, j'aimerais
bien qu'il éteigne réellement l'ordinateur lors d'un
shutdown -h et surtout j'ai envie de
voir une compilation. :-)
Je choisi la méthode Debian, qui est vantée dans
le chapitre 8.5 Compiler un nouveau noyau
comme plus simple que la méthode classique. Pourquoi
pas ? Mais je dois commencer par ajouter quelques
paquets d'après le document /usr/share/doc/kernel-package/README.gz.
Ensuite il faut faire une jonglerie entre les répertoires et
les utilisateurs que j'essayerai de comprendre
demain…
Je viens de me rendre compte que j'avais le serveur de police Freetype installé et que je n'avais pas encore profité d'installer les polices TrueType que j'avais reçues avec l'imprimante. J'espère que le résultat sera moins mauvais qu'avec la récupération des polices PostScript.
D'après
François Depierraz, la jonglerie des utilisateurs pour
créer un noyau à la mode Debian ne sert à rien, si ce
n'est à passer peu de temps en root. Je lance
donc sans plus tarder make xconfig.
Quelle joie de supprimer tous ces pilotes inutiles ! :-)
Mon .config se résume
à assez peu de choses.
XFig n'est finalement pas très pratique pour créer des fiches d'institutrice. Il s'agissait de faire un tableau de texte et de souligner quelques phrases. Finalement j'ai tapé du HTML dans Emacs que j'ai imprimé avec Mozilla M18. Le résultat n'est cependant pas bon. Aussi bien Mozilla que Navigator 4.76 s'acharnent à tout imprimer en Times.
Finalement je compile le noyau en suivant la méthode
Debian
(make-kpkg). J'ai même décidé d'utiliser le
système de flavour pour éviter d'écraser les
anciens modules. Le système est très simple, mais mal
documenté. Il s'agit simplement de suffixer la version du
noyau avec son propre texte. Ainsi je devrais avoir un noyau
2.2.18pre21fastboot. Ce qui n'est pas clair,
c'est qu'il faut patcher des fichiers pour que ce truc
fonctionne. Il y a bien un fichier /usr/share/doc/kernel-package/Flavours.gz
qui explique cela, mais il a été fait du temps du noyau
2.1.47 et mal maintenu depuis. À cette époque il semble que
plusieurs fichiers devaient être patchés. Mais à présent je
pense qu'il suffit de patcher le Makefile de
Linux. J'ai extrait le patch
de /usr/share/doc/kernel-package/Flavours.gz
et lancé patch
<~/Work/flavour.patch depuis le répertoire où
se trouve le Makefile.
Ensuite je compile mon noyau : make-kpkg
--revision=marc.1.0 --flavour=fastboot
kernel_image, ce qui me donne directement un
fichier
../kernel-image-2.2.18pre21-fastboot_marc.1.0_i386.deb.
J'installe le noyau par un dpkg -i
../kernel-image-2.2.18pre21-fastboot_marc.1.0_i386.deb.
Cela m'installe bien un
/boot/vmlinuz-2.2.18pre21-fastboot, un
/boot/config-2.2.18pre21-fastboot, un
/boot/System.map-2.2.18pre21-fastboot ainsi que
des liens /vmlinuz et /vmlinuz.old
sur le nouveau et l'ancien noyau. Les modules sont aussi bien
installés dans
/lib/modules/2.2.18pre21-fastboot/. Tout est
parfait, sauf le /etc/lilo.conf que
je vais encore arranger. Et le résultat est :
~# lilo -v -q
LILO version 21.5-1 beta, Copyright (C) 1992-1998 Werner Almesberger
'lba32' extensions Copyright (C) 1999,2000 John Coffman
Reading boot sector from /dev/sda
Global settings:
Delay before booting: 1.0 seconds
No command-line timeout
Enter boot prompt only on demand
Serial line access is disabled
No message for boot prompt
No default boot command line
Images:
Linux *
No password
Boot command-line won't be locked
No single-key activation
VGA mode: 9 (0x0009)
Kernel is loaded "high", at 0x00100000
No initial RAM disk
No fallback
Options: "ro root=802 BOOT_FILE=/vmlinuz"
LinuxOLD
No password
Boot command-line won't be locked
No single-key activation
VGA mode: 9 (0x0009)
Kernel is loaded "high", at 0x00100000
No initial RAM disk
No fallback
Options: "ro root=802 BOOT_FILE=/vmlinuz.old reserve=0xD400,32"
Le chargement est effectivement plus simple et rapide,
comme le montre les messages d'amorçage
sauvés par dmesg.
À part ça, il faut vraiment que je passe un peu de temps à régler Emacs. Il est affreusement lent, la coloration syntaxique à tendance à s'arrêter au milieu du document et le mode SGML prétend me dire comment je dois imbriquer mes balises HTML. :-(
xmotd et XDMJ'ai installé xmotd (encore à configurer)
pour pouvoir afficher des messages à l'ouverture des
sessions, xsnow pour amuser la galerie et le
paquet xfonts-jmk pour avoir plus de polices
X11. Mais je n'ai pas encore vu
ces polices, bizarre. La neige est très jolie en
revanche.
Bon, je vais m'amuser à configurer xmotd.
D'abord comprendre le démarrage de XDM. Alors nous
avons :
/etc/rc2.d/S99xdm
qui lance /usr/bin/X11/xdm./usr/bin/X11/xdm qui cherche par défaut sa
configuration dans /usr/lib/X11/xdm/xdm-config
qui est en fait un lien sur /etc/X11/xdm/xdm-config./etc/X11/xdm/xdm-config
est un fichier de resources (dont
DisplayManager.requestPort: 0 pour que XDM
n'écoute aucun port) listant d'autres fichiers de
resources et de scripts :
/var/log/xdm.log/etc/X11/xdm/xdm-keys/etc/X11/xdm/Xservers:0 en
l'occurrence), ainsi que leurs options de démarrage
(dont -nolisten tcp que j'ai ajouté pour
éviter que le serveur X écoute le réseau) ;/etc/X11/xdm/Xaccess/etc/X11/xdm/Xresources_0:0 ;/etc/X11/xdm/Xsetup_0:0,
pouvant lancer xconsole selon les options
de /etc/X11/xdm/xdm.options
et lançant /usr/bin/X11/xmodmap si
/etc/X11/Xmodmap
existe ;/etc/X11/xdm/Xstartup_0root par XDM
au début d'une session sur l'écran :0, se
contente d'appeler /etc/X11/xdm/Xstartup ;/etc/X11/xdm/Xreset_0root par XDM
à la fin d'une session sur l'écran :0, tue
un éventuel xconsole ;/etc/X11/xdm/Xresources/etc/X11/xdm/Xsetup:0 ;/etc/X11/xdm/Xstartuproot, ajoute
/usr/bin/X11 à
$PATH, vérifie si la session est autorisée
et le cas échéant la trace avec
sessreg ;/etc/X11/xdm/Xresetroot, enlève
la trace de la session avec
sessreg ;/etc/X11/Xsessionxdm en tant qu'utilisateur connecté (ou
xinit lors d'un démarrage par
startx) ;/etc/X11/xdm/xdm.options
est un fichier d'options de XDM créé pour Debian (voir man
xdm.options)./etc/X11/Xsession
est lancé. Il est documenté par man
Xsession. Il utilise /etc/X11/Xsession.options
pour ces options (man
Xsession.options). Il redirige toutes ses
sorties vers $HOME/.xsession-errors. Il
s'occupe des fichiers de resources dans /etc/X11/Xresources/
puis de /etc/X11/Xmodmap.
Il s'occupe des fichiers $HOME/.Xresources,
$HOME/.Xmodmap et $HOME/.xsession
selon les options de /etc/X11/Xsession.options.
Il choisi comme programme de session soit
$HOME/.xsession, soit
/usr/bin/x-window-manager et il le lance avec
/usr/bin/ssh-agent, ce qui a l'air d'être une
méthode très maligne de s'authentifier par la suite si on
ouvre des connexions SSH. Ce que je n'aurai malheureusement
certainement pas l'occasion de faire avant longtemps.Je découvre grâce à /usr/bin/x-window-manager
que Debian a une méthode
standard et documentée (man
update-alternatives) de gérer les programmes
alternatifs (et cela ne s'arrête pas aux gestionnaires de
fenêtres !) Cette distribution est vraiment
superbe.
D'après tout ce que j'ai lu (man
xdm et man xmotd),
/etc/X11/Xsession
est le script qui doit lancer xmotd. Mais la
francisation de xmotd par ses resources me pose
encore quelques problèmes. Le bouton Dismiss
résiste. Je pense mettre mes redéfinitions dans /etc/X11/Xresources/.
C'est d'ailleurs le répertoire indiqué par la
FAQ. Ainsi je ne toucherais pas aux définitions par
défauts de /usr/lib/X11/app-defaults/.
J'ai récupéré StarOffice chez Sun.
Un collègue m'a reformaté le disque ZIP que je lui avait
passé pour pouvoir faire tenir l'archive
so-5_2-ga-bin-linux-fr.bin dessus. C'est
intéressant, je croyais que les disques ZIP devaient avoir
une table des partitions, mais en fait il est possible de
mettre dessus uniquement un système de fichier. Et il faut
simplement monter /dev/sdc au lieu de
/dev/sdcn.
On se croirait vraiment sur Windows lorsqu'on installe
StarOffice. Le style d'installeur, la décoration des
fenêtres, il y a même une mise à jour des registres !
Pourvu que ça ne mette pas le fourbi dans mon installation
Debian. Je pourrai
peut-être installer cela sous un autre utilisateur que
root ?
Pas mal de trucs à faire aujourd'hui. En priorité,
installer StarOffice, puis activer xmotd pour
annoncer la bonne nouvelle. Puis chercher les sources de
xmotd pour voir pourquoi je n'arrive pas à
changer le texte du bouton Dismiss. En
parrallèle je télécharge 11 Mo de mise à jour Debian ! Quelques problèmes
avec le serveur X et des programmes associés…
J'ai bien fait de lire le ReadMe de l'installateur de StarOffice, il donne pas mal d'informations importantes :
Pour procéder à une installation en réseau (installation multiutilisateur), lancez (en tant que root) le programme setup à l'aide de l'option /net. Une fois l'installation en réseau terminée, chaque utilisateur souhaitant utiliser StarOffice devra lancer le setup à partir du répertoire de l'installation en réseau sous son propre identificateur (ID) (SANS /net). Une installation de station de travail (workstation) lui sera alors proposée. Celle-ci installera environ 2 Mo de données par utilisateur dans le répertoire home correspondant.
Pour démarrer StarOffice 5.2, vous exécuterez le script "soffice" que vous trouverez dans le répertoire d'installation, par ex. "/home/pierre/Office52/".
StarOffice pour Linux offre dès à présent la possibilité d'utiliser Java et JavaScript (lequel est réalisé de façon interne par l'intermédiaire de Java). Ceci avait jusqu'à ce jour échoué car il n'existait pas encore de Java Lib capable de supporter de façon appropriée les Threads natifs pour glibc2 requis par StarOffice. Une telle bibliothèque est à présent disponible. Afin d'activer ces nouvelles ressources, vous devez éditer le fichier de démarrage soffice qui fait partie des fichiers de StarOffice. Vous le trouverez, dans le cas d'une installation sur poste de travail individuel, dans le répertoire office52 et, dans le cas d'une installation en réseau, dans le répertoire correspondant sur le serveur.
StarOffice vous donne la possibilité de reparamétrer à tout moment l'environnement Java Runtime dont vous vous servez. Voici les étapes que vous devrez suivre ::
- Dans le dossier Bookmarks, ouvrez l'entrée "StarOffice Bookmarks/Java/Java Setup" - ceci affiche une boîte de dialogue permettant de sélectionner un environnement Java.
- Quittez StarOffice car il n'écraserait sinon les nouvelles entrées.
- Sélectionnez l'environnement Java qui devra être utilisé par StarOffice.
- Fermez la boîte de dialogue.
- Les nouveaux paramètres seront appliqués par StarOffice au prochain démarrage du programme.
ATTENTION : Il est absolument indispensable de quitter StarOffice avant d'enregistrer les paramètres : dans le cas contraire, toutes les modifications que vous avez apportées seront perdues !
J'utilise donc l'option -net de l'installeur
pour éviter d'installer une version par utilisateur !
Heureusement que Daniel Cordey m'avait
averti de cette combine. Ce StarOffice ressemble
peut-être un peu trop à Windows… Il y a même une
licence avec toutes les restrictions classiques. Au moins
elle élargit mon vocabulaire avec des traductions comme
rétrotechnique ou rustine. :-)
Pour faire les choses dans les règles, je devrais avoir un
répertoire /opt/.
Malheureusement je n'en ai pas. Je crée donc un /usr/local/opt/ à
la place. Je n'installe pas StarOffice Schedule 5.2 ni les
fichiers sonores. Une dizaine de méga-octets de gagnés.
À voir le résultat de find / -newer
/home/marc/HTML/Infomaniak/Marc/Guide/Journebian/index.html
StarOffice s'est installé proprement. Pas de modifications
louches en dehors de /usr/local/opt/office52/
StarOffice tient beaucoup de Windows, notamment par le
manque de manuels. J'ai lancé à tout hasard
/usr/local/opt/office52/program/soffice
(note du 17 février : oui, je sais, tout était en fait
expliqué dans le ReadMe de l'installation, mais j'avais
oublié son existence), ce qui m'a installé une configuration
utilisateur. Pendant un instant j'ai crû que tout
(260 Mo) allait être installé dans mon compte.
Heureusement ce n'est qu'une option ! En revanche il n'y
a même pas de JRE compris dans tous ces
méga-octets. Et j'ai sans doute installé un connecteur Adabas
pour rien ; quoique le rôle de ce composant n'est pas
très clair.
Ce StarOffice contient vraiment tout et n'importe quoi. Je
relance
/usr/local/opt/office52/program/soffice,
j'arrive dans un desktop qui me demande si je
veux paramétrer Internet. Non, ça ira comme ça. Pour
configurer l'imprimante de manière centrale, il faut que je
puisse éditer les fichiers de /usr/local/opt/office52/.
J'ajoute donc l'utilisateur marc au groupe
staff plutôt que de lancer StarOffice en tant
que root : adduser marc
staff. Malheureusement ça ne suffit pas car
certains répertoires ne respectent pas le mode
drwxrwsr-x. Je change donc les
droits d'accès de /usr/local/opt/office52/share/xp3/.
Une autre activité m'a occupée aujourd'hui, mettre à jour
mon installation pour éviter les trous de sécurité. Ce qui
m'a donné une excellente raison de désinstaller les paquets
qui ne me servent à rien. Cela réduit la taille des mises à
jour. D'ailleurs j'ai toute une série de paquets dont je
doute de l'utilité : xprt,
xnest, xvfb, xmh,
twm, xserver-vga16,
xproxy, rstartd. Je supprime déjà
twm et xserver-vga16.
Je compte régler mes petits soucis de configuration de
xmotd en allant directement regarder dans les
sources. Mais pour cela il faut que je trouve les sources.
J'ai essayé avec apt-get source xmotd
après avoir décommenté les lignes suivantes de /etc/apt/sources.list :
deb-src http://non-us.debian.org/debian-non-US stable non-US
deb-src http://http.us.debian.org/debian stable main contrib non-free
Mais apt-get source xmotd me
retourne une erreur bizarre :
~# apt-get source xmotd
Reading Package Lists... Done
Building Dependency Tree... Done
E: Could not open file /var/state/apt/lists/non-us.debian.org_debian-non-US_dists_stable_non-US_source_Sources - open (2 No such file or directory)
J'ai repris dans mon sources.list des lignes
du /etc/apt/sources.list
envoyé
par Marc Schaefer et maintenant je peux récupérer les
sources de xmotd par un simple
apt-get source xmotd :
~/DL$ apt-get source xmotd
Reading Package Lists... Done
Building Dependency Tree... Done
Need to get 36.1kB of source archives.
Get:1 http://sunsite.cnlab-switch.ch potato/main xmotd 1.14b3-1.2 (dsc) [622B]
Get:2 http://sunsite.cnlab-switch.ch potato/main xmotd 1.14b3-1.2 (tar) [25.9kB]
Get:3 http://sunsite.cnlab-switch.ch potato/main xmotd 1.14b3-1.2 (diff) [9593B]
Fetched 36.1kB in 18s (2004B/s)
dpkg-source: extracting xmotd in xmotd-1.14b3
Marc m'a aussi
confirmé que les paquets qui me semblaient inutiles les
lui semble également. Alors j'enlève xmh,
xnest, xproxy, xprt et
xvfb.
J'ai aussi enfin envoyé une carte postale à Andreas Klemm, l'auteur d'Apsfilter.
Le source de xmotd est vraiment mal écrit,
mais bien commenté et très court. Le problème est facile à
voir. Je ne peux pas changer le texte du bouton
Dismiss car il est fixé en dur par le programme,
tantôt en Dismiss, tantôt en Next
Message. Je pense qu'il est assez facilement possible
de corriger le programme en créant deux boutons, jamais
visibles simultanément. Mais pour cela il me faut de la
documentation de programmation. Le sujet 48 du document
comp.windows.x.intrinsics
Frequently Asked Question semble répondre à ma
question.
Marc Schaefer m'éclaire sur quelques questions
(xfs, anXious &
XF86Setup, lynx &
w3m, apt-setup, l'horloge et les
disques ZIP) posées dans Journebian.
Depuis que je me suis fait mon propre noyau, deux petits
avertissement concernant des modules sont apparus à
l'amorçage : Loading modules: vfat nls_iso8859-1
nls_cp850 sg modprobe: Can't locate module sg et
modprobe: modprobe: Can't locate module
char-major-10-135. D'après la documentation du noyau
(Documentation/scsi.txt),
sg est le module SCSI générique,
que j'avais compilé pour lire divers types de CD. L'avais-je
compilé comme module ? Il me semblait que oui, mais
peut-être ai-je été prudent et il est dans le noyau ?
Mon .config indique
que c'est inclu dans le noyau et grep sg
/boot/System.map-2.2.18pre21-fastboot me donne
pas mal de symboles commençant par sg_.
Pour ce qui est de
char-major-10-135, mon modules.conf contient
la ligne alias char-major-10-135
rtc. Or mon
.config contient la ligne #
CONFIG_RTC is not set. Il semblerait donc que
les deux cas soient causés par une faiblesse de la
maintenance des modules de Debian. Il est temps pour un
man update-modules.
D'après man update-modules il
suffirait de mettre à jour les fichiers du répertoire
/etc/modutils/.
Mais d'abord j'aimerais mieux comprendre pourquoi ces deux
modules précis posent problème. En effet, modprobe
-c donne une énorme liste d'alias de modules et
je n'ai que deux problèmes.
J'ai trouvé pourquoi le module
char-major-10-135 pose problème. Selon
man hwclock, hwclock
essaie d'abord de passer par /dev/rtc pour
accéder à l'horloge matérielle. Il faudra donc que je me
fasse un nouveau noyau, avec support RTC. Si les messages des
scripts d'initialisation étaient tracés, j'aurais peut-être
trouvé cela un peu plus vite.
Pour le cas de sg, le problème est causé par
le fichier /etc/modules qui
contient la liste des modules à charger à l'amorçage du
système. Comment sg a-t-il atterri là ?
D'après la date du fichier, il semble qu'il s'agisse des
modules supplémentaires que j'avais sélectionné lors de
l'installation de la Debian. La procédure Debian de
création de noyau propre oublierait donc ce fichier.
En outre lsmod indique que les
autres modules chargés à l'amorçage (nls_cp850,
nls_iso8859-1 et vfat) sont
inutilisés. J'ai l'impression que le nettoyage automatique
des modules ne fonctionne pas. D'après les documentations il
est basé sur cron. Je n'ai encore rien touché du
côté de cron, peut-être que ça ne fonctionne
pas ? À moins que les modules inutiles ne soient
déchargés qu'une fois par jour ? À voir…
Marc Schaefer a envoyé un exposé très complet des bonnes raisons de charger les modules à l'amorçage du système. Voici l'extrait qui m'intèresse le plus :
- lenteur: certains drivers causent des arrêts temporaires lors de leur
chargement, p.ex. certains pilotes SCSI (chargement du firmware,
scan du bus, etc), et en général ce qui a à faire avec du matériel.
- intégrité: charger un driver peut parfois resetter un périphérique
(p.ex. charger un pilote SCSI dynamiquement peut rembobiner une
cassette).
- fonctionnement: certains drivers ne fonctionnent pas correctement
s'ils ne peuvent pas allouer une mémoire contiguë ``importante'',
et cela ne peut se faire que rapidement après le démarrage.
p.ex.: driver st (SCSI tape).
- sécurisation: une machine sécurisée ne devrait pas tourner kmod
et une fois le démarrage effectué devrait supprimer le chargement de
modules via secure-level (ainsi que /dev/kmem, /proc et autres mais
cela est une autre histoire).
Je vais donc essayer de vérifier ces points la prochaine fois que je configurerai mon noyau.
En attendant je vide /etc/modules et tente
un réamorçage du système… et ça fonctionne ; je
peux encore monter un disque ZIP formaté
VFAT.
Marc Schaefer a encore envoyé de très beaux exemples de gestions des fuseaux horaires. Pour la question des heures d'été, j'ai de quoi méditer :
PS: encore une commande intéressante, je te laisse essayer et imaginer la
portée de celle-ci
zdump -v /usr/share/zoneinfo/MET | more
Côté sécurité,
François depierraz a posté une URL sur le site Openwall Project qui propose
notamment un programme nommé scanlogd.
Il pourrait m'être utile pour surveiller les accès à mon PC
lorsque je suis connecté à Internet. Et plus systématique que
mes observations de traces de
tcpdump…
cronEn essayant de comprendre le déchargement automatique des
modules, qui ne semble pas exister sur Debian, j'ai inspecté
cron :
/etc/crontab
n'indique que de lancer anacron une fois par
jour, semaine ou mois, par des lignes de la forme
suivante :25 6 * * * root test -e /usr/sbin/anacron ||
run-parts --report /etc/cron.daily.anacron, qui est aussi lancé une fois par
les scripts d'amorçage du système, fait ce qui est indiqué
dans /etc/anacrontab,
si ça n'a pas encore été fait ce jour/semaine/mois (un
fichier spécial contient la date de la dernière
exécution)./etc/anacrontab
contient des lignes de la forme :1 5 cron.daily nice run-parts --report
/etc/cron.daily.lpd et les
modemsLongue période sans avoir le temps de m'intéresser à mon installation. Mais j'ai échangé quelques courriers intéressants avec les membres du GULL :
lpd écoute toujours un port
TCP.auto et noauto dans /etc/modules pour le
lancement de kerneld qui est désormais
obsolète.Par défaut swapon -a ne donne pas
la même priorité à chaque partition de swap. Ce qui fait que
le paralellisme attendu n'est pas exploité. Il faut mettre
explicitement les priorités dans /etc/fstab :
/dev/sda5 none swap sw,pri=1 0 0
/dev/sdb1 none swap sw,pri=1 0 0
Ainsi swapon -s montre bien que
les deux partitions sont utilisées :
~$ swapon -s
Filename Type Size Used Priority
/dev/sda5 partition 128512 248 1
/dev/sdb1 partition 128512 252 1
Il me reste à vérifier que c'est plus rapide, ce qui n'est
pas évident, /dev/sdb étant plus lent que
/dev/sda. J'ai écrit un petit programme qui se
fork et accède aléatoirement aux données d'un
tableau. La différence n'est pas flagrante. Mais des accès
aléatoires ne représentent sans doute pas une charge
réaliste.
Aujourd'hui, apprentissage express de Tcl pour mon
travail. Heureusement il semble que j'ai déjà installé
l'environnement de développement. En tout cas
tclsh fonctionne bien.
J'aimerais bien faire un petit service Web qui permet d'envoyer une image et retourne une page HTML contenant diverses compressions d'une image. J'installe donc Apache. Juste un petit problème à régler :
apache: cannot determine local host name. Use the ServerName directive to set it manually. /usr/sbin/apachectl start: httpd could not be started Configuration failed! Run "apacheconfig" to try this again later.
Rien à faire avec apacheconfig, il ne me
reste plus qu'à éditer (l'excellent) /etc/apache/httpd.conf.
D'ailleurs il y a pas mal de valeurs à changer pour mon
serveur d'amusement :
Port 80 -> Port 8888MinSpareServers 5 ->
MinSpareServers 1MaxSpareServers 10 ->
MaxSpareServers 3StartServers 5 -> StartServers
1Ludwin a eu le même problème avec Apache et
m'a conseillé de donner une valeur à
ServerName. Je ne suis pas le premier à
rencontrer ce problème, comme en témoigne le
bug 65335. En entrant la directive ServerName
yok-yok dans /etc/apache/httpd.conf
apache démarre bien.
Du côté de Tcl, j'ai trouvé une bibliothèque cgi.tcl qui a l'air excellente. Mais il faut encore que je réflechisse à la meilleure manière de l'installer.
En jouant avec un CGI en Tcl, je remarque que Junkbuster
met par défaut un en-tête HTTP HTTP_USER_AGENT:
Mozilla/3.01Gold (Macintosh; I; 68K). Comme il
n'y a pas de raison que j'augmente artificiellement le nombre
de visiteur avec un Macintosh, j'ajoute la ligne suivante
dans /etc/junkbuster/config :
user-agent .. Maintenant je laisse de jolie
petites traces Mozilla/4.76 [en] (X11; U;
Linux 2.2.18pre21-fastboot i586).
Après avoir dû vaincre une incroyable fatigue, j'ai enfin
terminé mon premier script CGI en Tcl. Je ne comprends pas
tout à fait comment le système de paquet de ce langage
fonctionne. J'ai suivi les premières étapes du guide
d'installation de la bibliothèque
cgi.tcl, c'est-à-dire ln -s
/usr/lib/tcl8.2 .. puis
./configure puis
make. Le make
m'a créé un fichier pkgIndex.tcl grâce auquel la
commande Tcl package require cgi est capable
d'utiliser le fichier cgi.tcl qui est dans le
même répertoire. J'ai copié cgi.tcl et
pkgIndex.tcl dans mon répertoire /usr/lib/cgi-bin/
et j'ai enfin pu développer mon script.
Ce script réalise un service très pratique qui j'avais vu jadis sur le Web. Il reçoit une image envoyée par le visiteur et lui retourne une page HTML avec plusieurs versions de la même image compressées dans une gamme complète de niveaux de qualité. Pour l'instant ce n'est applicable qu'au JPEG, mais je pense supporter le GIF en proposant une gamme de réductions du nombre de couleurs.
Comme mon script est certainement très mal sécurisé, il
faut absolument que je supprime le lancement d'Apache à l'amorçage :
update-rc.d -f apache remove.
En faisant une énorme mise à jour (plus 10 Mo téléchargés) j'ai remarqué que je pouvais configurer de manière centrale l'apparence 3D des applications utilisant Xaw. C'est en tout cas ce que je comprends des messages d'installation :
Setting up xaw3dg (1.3-6.9potato1) ... The Xaw3d libraries are now installed. To make your favorite Xaw programs (xedit, xfig, emacs) have the 3D look, install a .Xdefault file in your home directory, like the one in /usr/share/doc/xaw3dg/Xdefault file. (renamed to .Xdefault!) If you want to explicitly link your programs against the Xaw3d library, you need to replace "-lXaw" with "-lXaw3d" on the linker command line (final linking stage with gcc). Note: 3D scrollbars (arrowscrollbars) are *disabled*, please see /usr/share/doc/xaw3dg/scrollbars for more information.
À part ça, j'ai ajouté le site de Clay Shirky à mes liens. Il a l'air intéressant, comme l'écrit si bien un participant de Slashdot.
resolve(), unresolve()Marc Schaefer a analysé le problème de
ServerName que j'ai eu avec Apache. Le fin mot de
l'histoire et que j'ai bien fait d'éditer le fichier /etc/apache/httpd.conf.
Mais
son analyse est bien plus complète et il a aussi rapporté
un bug à Debian.
Tiens, le noyau 2.2.19 est sorti. Je me demande combien de temps il me faudra pour me décider à l'installer… J'ai de la marge avant le 2.2.20, le 2.2.18 est sorti il y a plus de 3 mois.
Il y a juste un mois j'essayais de mesurer l'intérêt de répartir le swap sur mes deux disques. Je n'étais pas arrivé à un résultat concluant avec mon petit programme de test. J'ai ressayé avec un script qui se veut un peu plus réaliste :
#!/bin/sh
office52/soffice &
"time" -o t7 convert -despeckle img0001.pcd[4] img0007.jpeg &
"time" -o t6 convert -contrast img0001.pcd[4] img0006.bmp &
"time" -o t5 convert img0001.pcd[4] img0005.png &
"time" -o t4 convert -charcoal 25 img0001.pcd[3] img0004.jpeg &
"time" -o t3 convert img0001.pcd[3] img0003.png &
"time" -o t2 convert img0001.pcd[2] img0002.png &
"time" -o t1 convert img0001.pcd[1] img0001.png &
Cela reste un peu naïf, mais de toute façon il n'existe pas vraiment une charge typique. Comme le mois passé, je n'obtiens pas vraiment un résultat concluant. J'ai cependant tout de même réussi une fois à causer des messages d'alertes de la partie VM du noyau. Ce fut d'ailleurs accompagné d'un gel complet de la machine de quelques secondes.
Le ventilateur de mon alimentation fait un bruit vraiment infernal. J'ai essayé sans succès de le réparer. Il faudra que je change l'alimentation en plus du microprocesseur, de la carte mère et la mémoire, à l'occasion.
J'ai profité du démontage de mon boîtier pour voir le modèle de ma carte SCSI. C'est un peu bizarre, il y a deux noms inscrits : ABP-930 / 40U et ABP-960 / 70U.
À partir de maintenant je vais configurer les choses par ordre d'énervement décroissant (à l'exception du delete dans Emacs) Alors pour commencer il y a le passage d'un écran virtuel de FVWM à l'autre par simple déplacement de la souris qui m'énerve.
La configuration de FVWM dans Debian est bien expliquée dans
/usr/share/doc/fvwm/README.sysrc.gz.
C'est un classique système à crochets. Enfin celui de
Red Hat semblait assez
proche, ce qui n'avait pas empêcher une mise à jour de
détruire tous mes réglages. Mais avec Debian j'ai
confiance.
Les fichiers à accrocher sont dans /etc/X11/fvwm/.
Comme indiqué dans /etc/X11/fvwm/system.fvwm2rc,
il suffit d'ajouter EdgeScroll 0 0 dans /etc/X11/fvwm/post.hook.
Déjà une bonne chose de faite !
Second point ennuyeux, Emacs utilise par
défaut une police trop grande, ne colorie pas la syntaxe et
crée des fichiers de sauvegarde. À nouveau Debian est mieux que ma vieille
Red Hat. L'ajout de documentation au format info
est automatiquement reporté dans la racine de la
documentation. En l'occurrence il s'agit de
Emacs-lisp-intro.
Pour faire des essais de configuration, j'utilise mon
fichier .emacs mais j'aimerais appliquer les
résultats définitifs à tous les utilisateurs. Le fichier
/etc/emacs/site-start.el
est manifestement prévu pour cela.
J'ai déjà trouvé deux réglages qui me semblent bons :
(global-font-lock-mode 1) pour colorer la
syntaxe et (setq make-backup-files nil) pour que
Emacs ne
crée pas automatiquement des fichiers de sauvegarde.
Pour la police, j'hésite encore un peu. La manière
préconisée semble être de mettre une ligne comme
emacs.font: -misc-fixed-medium-r-semicondensed--13-*-*-*-c-60-iso8859-1
dans son fichier .Xdefaults. Pourquoi pas, mais
j'aurais voulu un peu mieux comprendre le fonctionnement des
fontset de Emacs d'abord. Et
puis, s'agissant d'une configuration de X, c'est pour un
chapitre suivant…
J'ai mis les commandes de configuration en Lisp dans
/etc/emacs/site-start.el,
ça fonctionne bien. En outre j'ai créé un /etc/X11/Xresources/emacs
pour indiquer la police d'Emacs, ça fonctionne
aussi bien.
Je viens de trouver une première solution intéressante à
mes satanés problèmes de blocage des connexions par modem.
C'est le mode V90 qui pose problème. Grâce à un mode d'emploi
des commandes AT des puces Rockwell, j'ai trouvé la commande
+MS=11,1,300,33600.
Je suis en train d'observer un ping régulier
comme un métronome, c'est la joie. :-) Tout s'est amélioré
d'un coup. Il ne me reste plus qu'à voir s'il est possible
d'obtenir de bons résultats au-dessus de 33600 bps.
Aujourd'hui j'ai trouvé un excellent manuel Debian qui décrit notamment l'installation mieux (captures d'écran) que je l'ai fait. Il s'agit du Dwarf's Guide to Debian GNU/Linux.
Quelques resources pour rendre XTerm plus agréable :
! Icône dynamique
*VT100.activeIcon: true
! Couleur du pointeur
*VT100.pointerColor: blue
! Barre de défilement
*VT100.scrollBar: true
! Lignes d'historique
*VT100.saveLines: 2047
! Flash au lieu de bip
*VT100.visualBell: true
Aujourd'hui je rends FVWM plus agréable. Voici ce que
j'ai trouvé jusqu'à présent (dans /etc/X11/fvwm/post.hook) :
# Suppression du passage 'automatique' d'un écran virtuel à l'autre.
EdgeScroll 0 0
# Déplacement des fenêtres avec leur fond.
OpaqueMoveSize 100
# Colle automatiquement les fenêtres proches.
SnapAttraction 5 SameType
# Placement automatique des nouvelles fenêtres.
Style "*" SmartPlacement
Style "*" RandomPlacement
# Le focus suit la souris sauf quand elle va sur le fond d'écran.
Style "*" SloppyFocus
# MMB met la fenêtre en arrière-plan (souvenir de MWM…)
Mouse 2 ST A Lower
# Menu contextuel
Mouse 3 ST A Popup Window-Ops
# L'horloge a un style particulier.
Style "xclock" NoTitle, Sticky, StaysOnTop, Handles, HandleWidth 5
J'ai encore ajouter une décoration amusante dans /etc/X11/fvwm/default-style.hook.
Il s'agit d'une texture dans
le titre des fenêtres. Pour l'occasion j'ai créé un
répertoire /usr/local/share/pixmaps/ :
AddToDecor default-decor
+ TitleStyle ActiveUp TiledPixmap /usr/local/share/pixmaps/blue-pattern.xpm
Il existe un code de pays pour les modems comme le mien.
D'après ce que j'ai trouvé, cela permet au modem de connaître
les particularités du réseau téléphonique de chaque pays.
Logiquement la commande AT*NC15 suivi
de ATZ devrait régler mon modem pour
la Suisse. AT*NC15 retourne bien
Switzerland, mais ATI7
n'affiche rien alors que je m'attendais au code. Je n'ai
cependant pas exactement la bonne documentation. En outre le
fonctionnement de ce AT*NC15 n'est
pas tout à fait clair. En tout cas, les connexions V90 ne
sont pas améliorées, je reste donc à 33600 bps.
J'aime bien avoir une invite de shell qui se détache bien
des caractères normaux. Je pense utiliser du rouge gras. Il
me semble avoir trouver un moyen solide de régler ceci. Voici
un extrait de mon .bashrc :
rouge=`tput setaf 1`
gras=`tput bold`
attr0=`tput sgr0`
PS1="${gras}${rouge}\w\\\$${attr0} "
Malheureusement XTerm semble compter les caractères d'échappement comme des caractères normaux, ce qui décale à gauche la marge de droite d'autant de caractères. C'est très génant. Il faut que je trouve une combine.
Il faudra aussi que je trouve un fichier plus général que
mon .bashrc lorsque tout sera bien fait.
Debian a mis en ligne
le dernier noyau (2.2.19) car il contient pas mal de
corrections au niveau sécurité. Mais la procédure de mise
à jour n'est pas très claire. Elle n'est pas automatique pour
les noyaux. Il faut utiliser wget et
dpkg. J'aimerais uniquement prendre les
nouvelles sources pour les compiler. Mais il faut que je
relise la documentation pour trouver quels sont les fichiers
intéressants.
J'ai trouvé sur le site VT100.net des documentations sur les terminaux dont les émulations sont tellement populaires sur Unix. J'espère que cela sera utile pour ma configuration de XTerm.
Aujourd'hui je m'approche sensiblement de la terre promise, du Saint Graal, du nirvana de la configuration : j'ai trouvé un moyen identique pour effacer les caractères à droite du curseur dans Bash et Emacs dans la console et dans X ! C'est Ctrl-d. Cela fonctionne même dans Netscape Navigator (Motif en fait je suppose).
Cependant, je ne dois pas me laisser aveugler par l'allégresse d'une telle avancée. Le but est d'atteindre cet objectif avec la touche Delete.
Pour rester dans le domaine des caractères récalcitrants, le problème de retour prématuré à la ligne n'est pas dû à XTerm, mais à la bibliothèque GNU Readline. En fait c'est dû au concept boîteux des caractères d'échappement, mais c'est trop tard pour revenir sur ce concept. En clair, il se passe ceci :
Sans Readline ni XTerm, par exemple dans la console après
avoir lancé bash --noediting, la
coloration syntaxique est bonne, ainsi que le retour à la
ligne. Mais une fois le retour à la ligne effectué, il n'est
plus possible de revenir à la ligne précédente. Ce qui est
malcommode pour éditer les commandes sur plusieurs lignes. En
revanche, la bibliothèque Readline se débrouille pour
permettre de revenir avec le curseur dans les lignes
supérieures. Ce que l'option reverse-wraparound
de XTerm devrait aussi permettre (pas testé). Le problème de
Readline est que pour faire ce petit traitement de lignes,
elle calcule la longueur de l'invite, mais en considérant les
séquences d'échappement comme des caractères imprimables.
D'où un affreux fourbi. Or je n'ai pas envie de perdre mon
invite colorée. Mais je ne supporterait pas non plus de
perdre les avantages de Readline (complétion de commandes,
édition multiligne…) Je ne vois pas d'option de
Readline pour laisser XTerm se débrouiller avec les retour à
la ligne. La seule s'en approchant est
horizontal-scroll-mode qui ne fait pas vraiment
ce que je veux. Peut-être zsh gère-t-il cela tout
différemment ? À voir,
je pose la question au GULL.
Félix Hauri m'a donné une excellente idée que j'essaie sur le champ : ne pas avoir l'invite sur la même ligne que la commande. N'étant plus géné par la taille de l'invite, j'en profite en plus pour ajouter l'heure et l'utilisateur :
couleur=`tput setaf 1`
attr0=`tput sgr0`
PS1="${attr0}${couleur}\t \u \w${attr0}\n"
J'ai téléchargé le noyau 2.2.19. À tout hasard j'ai même
gardé le .deb. Il est conservé dans /var/cache/apt/archives/.
Il me semble que ce répertoire contient quelques autres
.deb que je ne souhaite pas conserver. C'est
étrange.
L'installation des sources
(kernel-source-2.2.19_2.2.19-2_all.deb en
l'occurrence) est aussi un peu bizarre. Elle se contente de
créer un petit répertoire de documentation /usr/share/doc/kernel-source-2.2.19
et de poser une archive
kernel-source-2.2.19.tar.bz2 dans /usr/src/. Je décompresse
cette archive au même endroit que le noyau précédent dans
/usr/local/src/Linux/.
bzcat /usr/src/kernel-source-2.2.19.tar.bz2 |tar
xv.
J'hésite à supporter les TCP syncookie. En effet, ils ne
sont pas activés par la configuration réseau de Debian que j'ai trouvé dans
/etc/network/options.
Comme je ne compte pas être serveur, je crois que je n'en ai
vraiment pas besoin.
Configuration terminée. Dommage qu'un
message expliquant comment récupérer une ancienne
configuration n'ait été posté que le 9 mai 2001, mais
j'aurais aussi pu chercher un peu plus. make-kpkg
clean. make-kpkg --revision=marc.1.0
kernel_image. dpkg -i
../kernel-image-2.2.19_marc.1.0_i386.deb.
L'installation de l'image fait automatiquement l'échange
entre les liens symboliques /vmlinuz et
/vmlinuz.old. Ainsi après l'exécution de LILO,
j'ai le choix entre Linux pour le nouveau noyau
2.2.19 et LinuxOLD pour l'ancien
2.2.18pre21-fastboot. J'ai juste dû faire une correction dans
/etc/lilo.conf car
il restait les paramètres de l'ancien ancien noyau
2.2.18pre21 de la distribution.
Il faudra aussi que je fasse bien attention de conserver le 2.2.18pre21-fastboot si le 2.2.19 que j'ai compilé n'est pas bon.
Je viens de redémarrer, pas de problème rencontré, avec un peu de chance j'ai compilé le noyau 2.2.19 pour la dernière fois. Les messages de démarrage ont un peu changé, mais rien de bizarre à signaler. Il est cependant intéressant de remarquer que le CD-ROM n'est plus détecté en tant que CD-ROM car j'ai mis la gestion du CD-ROM en module. D'ailleurs cette gestion fonctionne très bien.
Je crois qu'il est temps d'ôter de mes disques le noyau
boîteux venu avec la distribution d'origine. Malheureusement
il semble que ce noyau n'appartient à aucun paquet car
dpkg -S /boot/vmlinuz-2.2.18pre21 ne
trouve rien (alors que dpkg -S
/boot/vmlinuz-2.2.19 trouve
kernel-image-2.2.19). Reste la méthode
manuelle :
~# find / -name \*2.2.18pre21
/usr/local/src/Linux/kernel-source-2.2.18pre21
/boot/vmlinuz-2.2.18pre21
/boot/System.map-2.2.18pre21
/boot/config-2.2.18pre21
/lib/modules/2.2.18pre21
~# rm /boot/vmlinuz-2.2.18pre21
~# rm /boot/System.map-2.2.18pre21
~# rm /boot/config-2.2.18pre21
~# rm -r /lib/modules/2.2.18pre21
Voilà, j'espère ne pas en avoir trop fait… J'ai
gagné une place considérable sur la partition / en tout cas…
Je peux encore ôter les sources compressées de mon ancien
noyau compilé avec dpkg -P
kernel-source-2.2.18pre21. À la limite je
pourrais aussi supprimer le répertoire de sources puis la
configuration du noyau est mise dans le paquet
kernel-image et se trouve dans /boot/. Voyons… ça
fait 96 Mo pour le répertoire de construction, pas
d'hésitation, rm -r
kernel-source-2.2.18pre21 (ce noyau 2.2 efface à
une vitesse impressionnante par rapport au 2.0).
dialdDepuis que j'ai installé Debian, un message des scripts
d'amorçage me demande de lire /usr/share/doc/diald/README.Debian
pour configurer diald.
Je suis les instructions : ln -s ttyS0
modem, emacs /etc/diald/connect,
emacs /etc/init.d/diald,
/etc/init.d/diald
start. Il y a un problème au lancement de diald.
Les lignes suivantes sont ajoutées à /var/log/daemon.log :
Apr 22 14:18:33 yok-yok modprobe: modprobe: Can't locate module tap0 Apr 22 14:18:33 yok-yok modprobe: modprobe: Can't locate module tap1 Apr 22 14:18:33 yok-yok modprobe: modprobe: Can't locate module tap2 Apr 22 14:18:33 yok-yok modprobe: modprobe: Can't locate module tap3 Apr 22 14:18:33 yok-yok modprobe: modprobe: Can't locate module tap4 Apr 22 14:18:33 yok-yok modprobe: modprobe: Can't locate module tap5 Apr 22 14:18:33 yok-yok modprobe: modprobe: Can't locate module tap6 Apr 22 14:18:33 yok-yok modprobe: modprobe: Can't locate module tap7 Apr 22 14:18:33 yok-yok modprobe: modprobe: Can't locate module tap8 Apr 22 14:18:33 yok-yok modprobe: modprobe: Can't locate module tap9 Apr 22 14:18:33 yok-yok modprobe: modprobe: Can't locate module tap10 Apr 22 14:18:33 yok-yok modprobe: modprobe: Can't locate module tap11 Apr 22 14:18:33 yok-yok modprobe: modprobe: Can't locate module tap12 Apr 22 14:18:33 yok-yok modprobe: modprobe: Can't locate module tap13 Apr 22 14:18:33 yok-yok modprobe: modprobe: Can't locate module tap14 Apr 22 14:18:33 yok-yok modprobe: modprobe: Can't locate module tap15 Apr 22 14:18:33 yok-yok modprobe: modprobe: Can't locate module tty-ldisc-1
Mauvaise configuration ou dépendances manquantes ?
C'est à voir. Peut-être bien des dépendances, en effet,
/etc/diald/connect
indique que chat-1.9 ou plus récent est requis.
Or il ne me semble pas que chat soit installé.
Quoique… si dans le paquet ppp.
La description du paquet de diald indique
qu'il faut un support SLIP du noyau. Voilà sans doute
l'origine de mon problème de modules. Je vais devoir
recompiler mon noyau pour ajouter un module SLIP.
La meilleure méthode pour installer un nouveau noyau
2.2.19 sur l'ancien ne m'est pas encore familière. J'essaie
dpkg -i
../kernel-image-2.2.19_marc.1.1_i386.deb. Le
script d'installation me dit qu'il n'est pas bon d'avoir
laisser le répertoire /lib/modules/2.2.19/.
Je le renomme en .old. Je repance l'installation
et cette fois c'est impécable ; l'ancien noyau 2.2.19 a
bien été remplacé par le nouveau tandis que mon
2.2.18pre21-fastboot éprouvé est toujours là au cas ou.
En fait la logique apparaît dans le nom du paquet. Le
caractère _ servant de séparateur, la version
est marc.1.1, le paquet étant
kernel-image-2.2.19, et non
kernel-image.
C'est le moment de relancer la machine… Jusqu'ici
tout va bien… Les messages d'amorçage de
diald et WWWOFFLE ont changé :
Starting diald: fifo-created diald. [...] 148 ? S< 0:00 /usr/sbin/diald Starting HTTP cache proxy server: wwwoffled. WWWOFFLE Now In Autodial Mode
Bien, après quelques réglages triviaux dans /etc/diald/connect,
je me connecte bien. Quelques messages obscurs apparaissent
cependant dans /var/log/messages :
Apr 22 15:30:48 yok-yok diald[148]: start ppp0: SIOCSIFMETRIC: Operation not supported [...] Apr 22 15:32:58 yok-yok diald[148]: start sl0: SIOCSIFMETRIC: Operation not supported [...] Apr 22 15:32:58 yok-yok diald[148]: start sl0: SIOCSIFMETRIC: Operation not supported Apr 22 15:32:58 yok-yok diald[148]: start sl0: SIOCADDRT: File exists Apr 22 15:32:58 yok-yok diald[148]: start sl0: SIOCADDRT: File exists
J'espère que ce n'est rien de grave. Il me reste à régler
deux trois combines. Par exemple le fait que la connexion
soit interrompue automatiquement après 30 secondes
d'inactivité, un peu court ! Avec connect-timeout
600 au lieu de connect-timeout 90 dans
/etc/diald/diald.options
ça devrait aller (en fait non). Il sera intéressant de
configurer un calcul automatique de la taxe téléphonique. Je
suspecte aussi chat de configurer le port série
à 38400 bps (en fait c'est diald qui
configure ce port).
La configuration de diald étant assez
tarabiscotée, je vais la décrire dans les lignes
suivantes.
/etc/init.d/diald
efface et recrée avec les permissions idoines le fichier
FIFO définit dans /etc/diald/diald.options.
Ce fichier FIFO est un canal pour envoyer des commandes
(man diald-control en donne la
liste) au démon diald depuis un programme
comme dctrl. Ensuite il lance le démon
/usr/sbin/diald.diald lit d'abord le fichier de
configuration /etc/diald/diald.defs.
Ce fichier ne contient que des commandes prule
et var qui indiquent à diald le
format des divers paquets envoyés sur le réseau. Les
modifications sont formellement déconseillées.Le démon diald lit en second lieu le
fichier de configuration /etc/diald/diald.options.
Ce fichier contient la partie intéressante de la
configuration : nom du fichier de trace, de FIFO, de
script de connexion chat (/etc/diald/connect),
routes locales, mode PPP, paramètres pour
pppd, routage.
Étonnament diald s'occupe aussi de
configurer le modem. Ce n'est donc pas chat
qui limite le modem à 38400 bps. La commande
speed 115200 de diald corrige cela.
Il y a aussi plein de timeout définissables. Dont un
système intéressant pour déterminer l'opportunité de
raccrocher. Il ne s'agit pas d'un simple temps limite,
mais plutôt de tenir compte des tranches de facturation.
Comme Sunrise
facture au centime, c'est cependant moyennement utile. En
plus l'interaction de ce timeout avec ceux définis dans
/etc/diald/standard.filter
(inclu à la fin) rend les opération assez difficiles à
prévoir. Aujourd'hui je reste donc avec un timeout de 2
minutes après la dernière connexion HTTP.
/etc/diald/connect
est lancé pour établir la connexion.Je crois que j'ai compris le fonctionnement des timeout de
diald. En fait le fichier /etc/diald/standard.filter
indique combien de temps conserver la ligne après certains
types de connexion (HTTP, FTP…) Si le temps s'écoule
sans évennement notable, la ligne est raccrochée, pour autant
que l'on ne se trouve pas dans la partie d'attente
duration d'une tranche de communication définie
par la commande impulse.
Avec la facturation au centime, la tranche nocturne valant
45 secondes, je renonce à ce système. Il ne me reste plus
qu'à alonger les attentes dans /etc/diald/standard.filter.
En outre je corrige un petit bug, comme il se doit /etc/services définit
https, pas ssl comme attendu par la
configuration par défaut. D'ailleurs ce bug a déjà été
rapporté.
J'ai fait une petite bêtise, j'ai commencé par modifier le
fichier /etc/diald/dynamic.filter.
Or ce fichier semble inutile. C'est bizarre.
Je crois que j'ai fini de mettre de l'ordre dans ma
configuration de diald. Si les tests se passent
bien, je lancerai diald au démarrage du système.
Il y a un truc génant, c'est qu'il s'écoule plusieurs secondes entre le moment où l'àtablissement d'une connexion s'avère et celui où le modem commence décroche. J'aimerais bien savoir ce qui prend si long.
Aujourd'hui je sépare l'énorme document HTML Journebian en deux parties (installation et configuration) plus une table des matières minimaliste pour qu'il se charge plus rapidement.
Mozilla (M18) étant un peu lent sur ma machine, j'utilise encore Netscape Communicator (4.77). Mais il y a quelques problèmes persistants. D'abord un petit message d'erreur lorsque je lance le programme :
grep: /etc/netscape4/config: No such file or directory
egrep: /etc/netscape4/config: No such file or directory
Netscape: Ignoring unsupported format code in mailcap file: %{
Heureusement ce problème semble plus malpropre que génant. Le second problème est plus génant. La liste des forums auquels je suis inscrit est perdue entre chaque lancement. En outre je reçois toujours un message indiquant que la résolution du nom du serveur NNTP a échoué. Cependant il suffit de sélectionner OK pour résoudre le problème.
J'essaie d'abord de résoudre le problème en donnant un
autre nom pour ce serveur, soit news.dplanet.ch
au lieu de news.sunrise.ch. Ce n'est pas très
concluant. Je ne suis cependant pas totalement sûr que
Netscape porte toute la responsabilité ; le serveur ne
répond pas toujours et au niveau DNS j'observe toujours (avec
tcpdump -a) des requêtes un peu
étranges. Il faudra que mette au clair tout ça un jour.
La façon dont Debian
installe Netscape me semble un peut confuse. Ainsi
dselect m'indique que les versions 4.76 et 4.77
sont toutes deux installées. Comme pour les noyaux, la
version fait partie du nom du paquet. Mais pourquoi
faire ?
Une autre chose compliquée est le nombre de liens
symbolique suivis pour aboutir à un vrai fichier lorsqu'on
lance netscape :
/usr/bin/X11/netscape ->
/etc/alternatives/netscape ->
/usr/lib/netscape/477/communicator/communicator-smotif
-> ../../base-4/wrapper.
/usr/lib/netscape/base-4/wrapper est un gros
script qui met en place l'environnement de Netscape.
En plus il me semble que la première installation était un
peu ratée. J'ai peut-être fait une purge de trop. Maintenant
la situation est un peu bizarre. Par exemple si je demande à
dselect d'installer, il répond 0 packages
upgraded, 0 newly installed, 0 to remove and 1 not
upgraded. J'aimerais bien savoir quel est ce paquet
non mis à jour. J'aimerais aussi bien pouvoir vérifier que
les fichiers installés sont bons. dpkg
--audit ne retourne aucun problème, mais il ne
vérifie pas chaque fichier sur le disque.
Par exemple les message d'erreur de grep
viennent de deux fichiers de configuration du paquet
netscape-base-4 qui n'existent pas ou
plus : /etc/netscape4/environment et
surtout /etc/netscape4/config.
J'enlève déjà la version 4.76 pour voir ce qui se passe :
The following packages will be REMOVED: communicator communicator-base-476 communicator-smotif-476 netscape-base-476 netscape-java-476 0 packages upgraded, 0 newly installed, 5 to remove and 0 not upgraded. Need to get 0B of archives. After unpacking 22.5MB will be freed. Do you want to continue? [Y/n] (Reading database ... 48417 files and directories currently installed.) Removing communicator ... Removing communicator-smotif-476 ... Removing communicator-base-476 ... Removing netscape-java-476 ... Removing netscape-base-476 ...
J'arrive encore à démarrer Netscape, c'est bien.
Grâce à un courrier détaillé de Marc Schaefer je progresse dans ma vérification des paquets installés. Ainsi j'ai découvert une série étonnante de fichiers dont la somme MD5 ne correspond pas :
~# debsums -a -s
md5sum: MD5 check failed for 'usr/share/consolefonts/lat1u-16.psf.gz'
md5sum: MD5 check failed for 'etc/diald/dynamic.filter'
md5sum: MD5 check failed for 'usr/share/fonts/fontmap'
md5sum: MD5 check failed for 'usr/share/gnome/help/gnotepad+/C/index.html'
md5sum: MD5 check failed for 'usr/share/gnome/help/gnotepad+/C/index-5.html'
md5sum: MD5 check failed for 'usr/share/gnome/help/gnotepad+/C/topic.dat'
md5sum: can't open usr/share/doc/isapnptools/README.lib
md5sum: MD5 check failed for 'etc/junkbuster/config'
md5sum: MD5 check failed for 'etc/junkbuster/blockfile'
md5sum: MD5 check failed for 'etc/junkbuster/cookiefile'
md5sum: can't open sbin/ldconfig.new
md5sum: MD5 check failed for 'usr/bin/libtool'
md5sum: MD5 check failed for 'etc/pam.d/login'
md5sum: MD5 check failed for 'usr/lib/mozilla/chrome/installed-chrome.txt'
md5sum: MD5 check failed for 'etc/pam.d/passwd'
md5sum: can't open usr/bin/perl-5.005.dist
md5sum: MD5 check failed for 'etc/ppp/options.ttyXX'
J'ai aussi réinstallé avec apt-get install
--reinstall netscape-base-4 sans succès le
paquet netscape-base-4 pour retrouver le fichier
/etc/netscape4/config.
Finalement je me contenterai d'un touch
/etc/netscape4/config.
Cette fois j'emploie les grands moyens pour retrouver ce
fichier /etc/netscape4/config.
J'ai pris par FTP le .deb sur non-us.debian.org.
Ensuite dpkg-deb --extract
netscape-base-4_4.77-1_i386.deb nn et tous les
fichiers du paquet sont extraits dans le répertoire
nn. Le contenu du fichier config
est le même que
celui de Marc Schaefer. Puisque ça correspond, je copie à
la main les fichiers vers /etc/netscape4/config
et /etc/netscape4/environment.
Autre problème qui s'éclaircit, debsums -a
-s qui retourne des erreurs. Pour les fichiers
de gnotepad+ ça vient du fait qu'il
appartiennent aussi au paquet gnotepad+-help.
Les autres fichiers semblent effectivement être des
configurables. Sauf /usr/share/consolefonts/lat1u-16.psf.gz.
Révision (finale ?) de la partie Installation de Journebian.
XF86ConfigEn revoyant le début de cette partie de Journebian, je
reviens à la configuration du serveur X. Je décide de
récupérer quelques lignes de la configuration de
anXious qui paraissent intéressantes. D'abord la
Section "Files", avant :
Section "Files"
RgbPath "/usr/X11R6/lib/X11/rgb"
FontPath "/usr/X11R6/lib/X11/fonts/Type1/"
FontPath "/usr/X11R6/lib/X11/fonts/Speedo/"
FontPath "/usr/X11R6/lib/X11/fonts/100dpi/:unscaled"
FontPath "/usr/X11R6/lib/X11/fonts/75dpi/:unscaled"
FontPath "/usr/X11R6/lib/X11/fonts/100dpi/"
FontPath "/usr/X11R6/lib/X11/fonts/75dpi/"
FontPath "/usr/X11R6/lib/X11/fonts/misc/"
# ModulePath "/usr/X11R6/lib/modules"
EndSection
et après :
RgbPath "/usr/X11R6/lib/X11/rgb"
FontPath "/usr/lib/X11/fonts/misc/:unscaled"
FontPath "/usr/lib/X11/fonts/cyrillic/:unscaled"
FontPath "/usr/lib/X11/fonts/75dpi/:unscaled"
FontPath "/usr/lib/X11/fonts/100dpi/:unscaled"
FontPath "/usr/lib/X11/fonts/Type1/"
FontPath "/usr/lib/X11/fonts/Speedo/"
FontPath "/usr/lib/X11/fonts/misc/"
FontPath "/usr/lib/X11/fonts/cyrillic/"
FontPath "/usr/lib/X11/fonts/75dpi/"
FontPath "/usr/lib/X11/fonts/100dpi/"
ModulePath "/usr/X11R6/lib/modules"
Hier j'avais placé par erreur les polices à 75 points par pouce avant celles à 100 points par pouce dans la liste des répertoires de polices. Mais je n'aime pas les polices à 75 points par pouce dans Netscape Navigator. Je remets donc les chemins dans le bon ordre :
FontPath "/usr/lib/X11/fonts/misc/:unscaled"
FontPath "/usr/lib/X11/fonts/cyrillic/:unscaled"
FontPath "/usr/lib/X11/fonts/100dpi/:unscaled"
FontPath "/usr/lib/X11/fonts/75dpi/:unscaled"
FontPath "/usr/lib/X11/fonts/Type1/"
FontPath "/usr/lib/X11/fonts/Speedo/"
FontPath "/usr/lib/X11/fonts/misc/"
FontPath "/usr/lib/X11/fonts/cyrillic/"
FontPath "/usr/lib/X11/fonts/100dpi/"
FontPath "/usr/lib/X11/fonts/75dpi/"
Chouette, Je retrouve le sublime Adobe Times 12 points dans Navigator. En revanche les menus de Emacs sont maintenant d'une police genre Comics, pas terrible. Mais pas génant non plus. J'essaie tout de même un autre ordre :
FontPath "/usr/lib/X11/fonts/100dpi/:unscaled"
FontPath "/usr/lib/X11/fonts/misc/:unscaled"
FontPath "/usr/lib/X11/fonts/75dpi/:unscaled"
FontPath "/usr/lib/X11/fonts/cyrillic/:unscaled"
FontPath "/usr/lib/X11/fonts/Type1/"
FontPath "/usr/lib/X11/fonts/Speedo/"
FontPath "/usr/lib/X11/fonts/100dpi/"
FontPath "/usr/lib/X11/fonts/misc/"
FontPath "/usr/lib/X11/fonts/75dpi/"
FontPath "/usr/lib/X11/fonts/cyrillic/"
Cette fois tout me semble cohérent. Emacs utilise une
police Courier gras pour ses menus, Netscape Navigator de
l'Helvetica pour les menus et du Courier pour l'URL. En plus
toutes ces polices ont l'air d'être de la même taille.
J'aimerais bien réduire un peu cette taille. Ce qui tombe
bien car il y a justement eu
un échange sur les tailles de police très récemment entre
des membres du GULL.
Comme je ne sais pas très bien ou spécifier la police par
défaut, je crée un fichier /etc/X11/Xresources/x
qui contient la ligne *font:
-misc-fixed-medium-*-semicondensed-*-13-*-*-*-*-*-iso8859-1.
Pour le reste de la configuration de Netscape, je crée un
fichier /etc/X11/Xresources/netscape en suivant
les conseils de
http://www.mandrakeuser.org/docs/connect/cbrowse2.html.
Ces conseils sont assez variés, j'ai même trouvé comment
supprimer des boutons inutiles de la barre d'outils.
Je pourrais aussi essayer d'ajouter un serveur de polices une fois, notamment pour supporter les polices True Type.
J'ai aussi des polices PEX (dans /usr/lib/X11/fonts/PEX/)
installées. Mais d'après les informations de leur paquet,
elles ne servent qu'au module d'extension
/usr/X11R6/lib/modules/pex5.so. Je ne suis pas
sûr qu'une seule des extensions de XFree86 installée sur ma
machine serve. Je pourrais peut-être désinstaller le paquet
xext ? Un peu risqué pour l'instant.
Je finis de parcourir /etc/X11/XF86Config
et procède à quelques petits changements. J'ai ajouté la
ligne Option "pci_retry" dans la Section
"Device" de ma carte graphique. Il me semble que
l'interface est plus réactive maintenant. J'espère que je ne
rencontrerai aucun effet négatif. En effet, cette option est
désactivée par défaut car, je cite man
XF86_SVGA : This may cause bus
timeouts for some ISA DMA hardware (soundcards, floppy tape
drives, etc). Comme je n'ai aucune carte ISA, j'ai bon
espoir. En revanche j'ai quelques inquiétudes pour ma carte
PCI SCSI.
Enfin j'ai supprimé une Section "Screen" pour
le Driver "accel", inutile car ma carte Matrox
utilise le Driver "svga".
Voici donc mon fichier
XF86Config final.
J'ai trouvé un document qui contient quelques informations
intéressantes en relations avec mes configurations :
http://home.c2i.net/dark/linux.html.
Je me rends compte qu'il existe encore beaucoup d'aspects de
la gestions des polices que je ne connais pas du tout.
Des
échanges de courrier du GULL m'ont donné envie d'essayer
memtest86. Je l'ai pris à http://reality.sgi.com/cbrady_denver/memtest86/.
Je le compile et l'installe sur le disque dur avec LILO. Il
suffit d'ajouter les deux lignes suivantes dans /etc/lilo.conf :
image=/boot/memtest.bin
label=memtest
Je vais donc réinitialiser la machine pour essayer
memtest86. J'en profiterai aussi pour supprimer
l'amorçage par disquette car je crois qu'il est encore
actif.
J'ai laissé memtest86 tourner toute la nuit.
Finalement ce n'est pas tellement intéressant. Ce n'est qu'au
onzième test, après des heures, qu'il a détecté un problème
alors que j'avais enclenché avec le BIOS l'option SDRAM
Speculative Read. Pourtant avec cette option
enclenchée, je n'arrive même pas à lancer XDM !
En revanche l'option SDRAM CAS# Latency 2T au lieu de 3T ne semble pas poser de problème. L'accélération promise n'est toutefois pas très visible.
Tant qu'à touiller le BIOS, autant tout essayer. J'ai baissé à 1 BUSCLK le 16-bit I/O Recovery Time et le 8-bit I/O Recovery Time, bien que n'ayant aucune carte ISA, cela n'a certainement aucun effet, sauf peut-être sur quelque détection de matériel à l'amorçage du système. Ce qui a en revanche un effet est d'avoir désactivé le Boot Up Floppy Seek et d'avoir abaissé le délai d'attente de LILO. Pour LILO, je vais même supprimer ce délai et voir ce qui se passe… Tout va bien, je peux toujours choisir entre les images par Shift et Tab.
Comme je suis satisfait des réglages de mon shell, je veux
les étendre à tout le système. Les fichiers /etc/profile et
/etc/inputrc
font partie des fichiers de configuration du paquet
base-files. Le fichier /etc/bash.bashrc
fait partie des fichiers de configuration du paquet
bash. Je ne trouve pas trace de ce fichier dans
la documentation, mais une note de /usr/share/doc/bash/changelog.Debian.gz
semble indiquer qu'il s'agit d'une option de compilation de
Bash.
Le problème est que /etc/profile et
/etc/skel/.bashrc
donnent une valeur à la variable PS1. Pour être
cohérent, je commente la ligne PS1='\u@\h:\w\$ '
dans /etc/skel/.bashrc
puis je remplace dans /etc/profile
l'assignation de PS1 par les lignes
suivantes :
# set a fancy prompt
couleur=`tput setaf 1`
attr0=`tput sgr0`
PS1="${attr0}${couleur}\t \u \$PWD${attr0}\n"
De même je change umask 022 en umask
002 dans /etc/profile et je
commente cela dans /etc/skel/.bash_profile.
Petit problème, /etc/profile n'est
exécuté que par les shells de login. En revanche, d'après le
commentaire, /etc/bash.bashrc
est exécuté par les shells interactifs, juste ce qu'il me
faut. Après vérification, le commentaire est trompeur,
/etc/bash.bashrc
est exécuté dans les mêmes circonstances que
.bashrc. Je déplace donc dans /etc/bash.bashrc
ce qui se trouvait originellement dans mon
.bashrc et je fais sourcer ce fichier par
/etc/profile
si le shell est Bash (autrement on se contente d'un profile
simplifié).
À la prochaine occasion, j'essaierai les options associées
à la commandes shopt. Certaines ont l'air
intéressantes or seule shopt -s checkwinsize
existe dans le /etc/bash.bashrc
original.
Il y a 3 trucs qui me génaient dans l'historique de Bash.
Il était trop court, il conservait des répétitions de
commandes identiques et il perdait l'historique des shells
ouverts et fermés alors qu'un autre shell était ouvert. Je
crois que j'ai réussi à corriger tout ces défauts grâce aux
commandes suivantes dans /etc/bash.bashrc :
HISTCONTROL=ignoredups
HISTSIZE=32767
export HISTCONTROL HISTSIZE
unset HISTFILESIZE
shopt -s histappend
Et comme je n'utilise pas le courrier local je peux encore
éviter que Bash le vérifie pour rien. Ce qui me donne
finalement ce fichier
/etc/bash.bashrc.
Aujourd'hui j'ai découvert deux commandes intéressantes
pour explorer mon système. Au niveau matériel, il y a
lspci, dons voici le résultat :
lspci
00:00.0 Host bridge: Intel Corporation 430TX - 82439TX MTXC (rev 01)
00:01.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 01)
00:01.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01)
00:01.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01)
00:01.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 01)
00:0b.0 SCSI storage controller: Advanced System Products, Inc ABP940-U / ABP960-U (rev 02)
00:0c.0 VGA compatible controller: Matrox Graphics, Inc. MGA 2164W [Millennium II]
Et au niveau logiciel, editres permet
d'explorer la structure des fenêtres de programme, comme par
exemple Netscape Navigator.
Grâce à un
message de Marc Schaefer je comprends enfin un peu
concrêtement le principe du fichier .Xauthority
et de la variable XAUTHORITY. C'est assez simple
pourtant ça n'était jamais resté dans ma mémoire. J'ai créé
pour l'utilisateur root l'alias de commande
alias x='export DISPLAY=:0; export
XAUTHORITY=/home/marc/.Xauthority'. Cela me permet de
supprimer le xhost local: de mon utilisateur
marc.
dircolorsJ'ai toujours trouvé trop coloré la sortie de
ls --color=auto. Il est donc grand
temps de changer cela. Manifestement les couleurs par défauts
ont été compilées dans dircolors. Heureusement
il suffit de lancer dircolors -p >
dircolors.conf pour générer un fichier de
configuration. Ensuite je le modifie avec Emacs, puis je mets
le résultat dans
/etc/dircolors.conf. Ensuite j'ajoute les lignes
suivantes dans /etc/bash.bashrc :
eval `/usr/bin/dircolors /etc/dircolors.conf`
export LS_COLORS
Finalement il ne reste plus qu'à supprimer l'appel à
dircolors dans les fichiers .bashrc
des utilisateurs pour que le changement soit automatiquement
effectif.
Est-ce qu'un fond d'écran est plutôt lié à la session X ou
au gestionnaire de fenêtres. Je me pose la question car je me
demande s'il faut intervenir au niveau de
Xsession ou de FVWM. Il semble toutefois plus
simple d'intervenir au niveau de FVWM. En outre il me semble
relativement probable que d'autres systèmes de fenêtres plus
complexes proposent un fond d'écran, bien qu'étant aussi
lancé par /etc/X11/Xsession.
Je crée donc un fichier ~/.fvwm/post.hook
pour qui lance un programme changeant le fond d'écran avec la
commande Exec exec /usr/bin/X11/xsetroot -solid
black. C'est cependant un peu limité et j'en profite
pour installer quelques nouveaux paquets :
chbg, giftrans,
jpeginfo, libjpeg-progs,
xdaliclock et xscreensaver.
Finalement j'utilise chbg pour changer mon
fond d'écran. Il est lancé automatiquement par la ligne
+ "I" Exec killall chbg; exec chbg que j'ai mise
dans un fichier ~/.fvwm/init.hook. Le
killall n'est pas très élégant, mais je n'ai pas
trouvé comment arrêter chbg avec FVWM. Alors au moins je tue tous
les chbg possible avant d'en lancer un
nouveau.
Grâce à
un message de Félix Hauri je découvre les possibilités de
xvidtune. Jusqu'à présent mes réglages d'écran
étaient bons au démarrage du PC, en mode console et en
1152×864. Mais dans les plus basses résolutions de X, c'était
franchement décentré et mal dimensionné. Je change donc
quelques Modeline et ô joie, je peux passer de
1152×864 à 1024×768 à 800×600 à 640×480 à 320×200 avec un
écran bien réglé. Une telle joie doit être partagée ;-)
voici mon XF86Config avec les
nouvelles Modeline.
En lisant les sources du pilotes SCSI AdvanSys je vois
qu'il est possible de supprimer la recherche de cartes ISA ou
VL en passant le paramètre advansys=. J'ajoute
donc la ligne append="advansys=" dans /etc/lilo.conf et je
relance le système. Il n'y a pas de petites optimisations.
:-) Je ne sens pas de différence de vitesse cependant.
Dans mes recherches d'optimisation, j'ai trouvé un site fabuleux (PCGuide) expliquant en détails les standards SCSI et des dizaines d'autres sujets.
Marc Schaefer
me conseille d'utiliser scsiinfo du paquet
hwtools pour explorer ma configuration SCSI en
détail.
est sorti aujourd'hui, je l'installe et je l'essaie.
Gel complet de l'interface graphique, très désagréable, j'ai dû utiliser le bouton reset.
J'active le Tagged Command Queuing pour mon disque Seagate Medalist 1080sl. J'espère ne pas avoir de mauvaises surprises. Pour l'instant tout va bien.
Aucune mauvaise surprise avec les disques, chouette.
dselectD'après les avis convergents de
François Deppierraz et
Marc Schaefer, dselect n'est pas au point et
il vaut mieux directement utiliser Apt et dpkg.
Heureusement Marc m'a donné un lien sur
une bonne introduction à Apt et dpkg. En
effet, en lisant les seuls manuels il est difficile de
comprendre comment le tout s'articule.
Après avoir lancé pour la douzième fois par erreur Mozilla
M18 au lieu du Mozilla 0.9.1 installé dans mon répertoire, je
décide de purger M18. Tout se passe bien. Quelques
avertissements sur des répertoires non vides dans
/usr/lib/mozilla, mais à la fin tout a
disparu.
Un courrier de mon hébergeur Infomaniak indique qu'il a quitté le fournisseur d'accès Sunrise Freesurf à cause d'innombrables problèmes, dont des connexions V.90 défectueuses. Pour télécharger les 10 Mo de Mozilla 0.9.2 je vais donc essayer en V.90 par Infomaniak.
Hum, finalement je n'arrive même pas à établir fiablement
la connexion modem avec Infomaniak. Tant pis. Je garde en
commentaires les paramètres d'Infomaniak dans /etc/diald/connect
à tout hasard.
Maintenant il est trop tard pour Mozilla. :(
Je charge et j'installe Mozilla 0.9.2. Je garde quelques traces pour faire d'éventuelles entrées dans Bugzilla.
C'est le titre d'un échange très intéressant qui a eu lieu
dans la liste linux-leman du GULL à propos de divers moyens
de transférer des fichiers (par scp,
ssh, tar, cpio et/ou
rsync).
Il y a aussi eu
un échange rm -M sur la bonne manière de
protéger les noms de fichier pour les passer aux commandes
Unix. commande -- "$FILE"
est la bonne solution, mais -- est une
particularité GNU.
Après vérification, mon horloge avance de plus de 30
secondes. En fait je me rends juste compte que je ne vois pas
trace de connexion aux serveurs de temps avec
dctrl. ntpdate ne fonctionnerait
plus depuis que j'utilise diald ? Ou les
serveurs de temps ne sont-ils simplement plus atteignables
comme l'indique les lignes dans /var/log/daemon.log :
Oct 19 22:23:34 yok-yok ntpdate[1658]: no server suitable for synchronization found
Dans ma quête d'informations, j'ai trouvé la home de NTP et mes
anciens serveurs ne semblent effectivement plus exister.
J'utilise désormais ntp.univ-lyon1.fr et
ntp.karpo.cz.
Dans la foulée, j'ajoute l'option -B à
l'appel de ntpdate pour forcer un ajustement
doux de l'horloge.
De retour, après quelques mois d'intermède de vraie vie.
Donc… quelle est la manière standard d'ajouter une
utilisatrice sur Debian ? Il existe
adduser et useradd. D'après le
manuel, adduser se comporte selon la politique
Debian, avec création d'UID, GID, groupe
(usergroup), copie de squelette, répertoire dans
home. J'utilise l'option
--force-badname car j'aime avoir une majuscule
pour commencer un nom propre.
Il faut encore que je lui donne quelques droits en
l'ajoutant au groupe dialout dans /etc/group ainsi qu'avec
sudo dans /etc/sudoers. Et
j'ajoute dans .bashrc un alias pratique pour les
commandes qui passent par sudo :
alias down='sudo /sbin/shutdown -h now
Je supprime aussi les messages obsolètes dans /etc/xmotd/.
Pas beaucoup de travail, changer les variables
PHONE_NUMBER, USER_NAME et
PASSWORD dans /etc/diald/connect.
Pour gagner un peu en vitesse et pas mal en fiabilité,
j'utilise aussi un serveur DNS de mon nouveau provider
(Econophone) au lieu
de l'ancien (Sunrise
Freesurf), soit 195.129.112.101 au lieu de
194.158.230.54. Pour pouvoir envoyer des mails, je dois
encore changer de serveur SMTP,
mail.econophone.ch au lieu de
smtp.freesurf.ch.
apt-get et sources.listPour accélérer un peu le chargement de la liste de paquets
Debian et aussi parce
j'ai changé d'ISP, je supprime de /etc/apt/sources.list
les entrées :
deb http://sunsite.cnlab-switch.ch/ftp/mirror/debian/ potato main non-free contrib
deb-src http://sunsite.cnlab-switch.ch/ftp/mirror/debian/ potato main non-free contrib
En relisant un
article de Linuxnewbie.org je suis tombé sur une option
intéressante de apt-get pour faire du
ménage : apt-get autoclean. Une
commande plus efficace serait même apt-get
clean qui selon le manuel efface tout le cache
des paquets locaux.
J'essaie de récupérer des disquettes IMATION de 3M. J'ai
eu de très mauvaises expériences avec alors je me méfie.
Heureusement il semble possible de formater avec une bonne
vérification : superformat -v 2 --superverify
/dev/fd0 hd. Comme conseillé après mesure, je
crée un fichier /etc/driveprm avec la
ligne :
drive0: deviation=-2160
superformat crée automatiquement un système
FAT sur la disquette, mais pour cela je dois installer
mformat => apt-get install
mtools.
Je ne sais pas si c'est superformat, mon PC
ou Linux, mais les disquettes que je n'arrivais jamais à
formater correctement chez ma soeur passent mieux ici.
Fort de mon relatif succès avec superformat,
je décide de mettre un peu d'ordre dans mon tas de vieilles
disquettes. Pour utiliser superformat en tant
que marc plutôt que root, je dois
cependant m'ajouter au groupe floppy dans
/etc/group. Les
groupes sont vraiment bien préparés sur Debian, un plaisir à utiliser. À
l'avenir j'aurai certainement l'occasion de m'ajouter dans
d'autres groupes comme audio, tape,
games, video,
backup…
J'essaie d'installer une carte Ethernet prêtée par un ami
pour pouvoir brancher mon PC au sien demain. C'est une de ces
cartes à 20 francs toute simple. De Micronet.
Introuvable sur le Web, mais de toute façon c'est la puce qui
compte. lspci me donne 00:09.0
Ethernet controller: Realtek Semiconductor Co., Ltd.
RT8029(AS). Il ne me reste plus qu'à espérer que ce
soit supporté par mon vieux noyau 2.2.
D'abord retrouver mon noyau… J'avais installé et compilé le noyau 2.2.19 le 21 avril de l'année passée. D'après ce que je comprends je peux commencer par un :
make menuconfig
rm -f include/asm
( cd include ; ln -sf asm-i386 asm)
make -C scripts/lxdialog all
make[1]: Entering directory `/usr/local/src/Linux/kernel-source-2.2.19/scripts/lxdialog'
gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -DLOCALE -DCURSES_LOC="<curses.h>" -c -o lxdialog.o lxdialog.c
In file included from lxdialog.c:22:
dialog.h:29: curses.h: No such file or directory
make[1]: *** [lxdialog.o] Error 1
make[1]: Leaving directory `/usr/local/src/Linux/kernel-source-2.2.19/scripts/lxdialog'
make: *** [menuconfig] Error 2
Oula, non, en fait j'utilisais plutôt make
xconfig. Il y a un driver spécifiquement
pas pour ma puce : Realtek
8129/8139. Finalement par des voies à peine
détournées, j'apprends que cette puce est compatible NE2000.
La page Using PCI
NE2000 Cards with Linux donne plein
d'explications.
Je me serais volontiers contenté d'ajouter un module à mon
noyau, mais le support Ethernet n'est pas modulable. Donc je
fais un nouveau noyau. Je ne me souviens plus très bien quoi
lancer, d'après mes notes, à tout hasard :
make-kpkg --revision=marc.1.0
--flavour=micronet
Beuh, ça n'a rien produit. Zut. Bon, à vrai dire je ne me
souviens plus très bien de la différence entre une
revision et une flavour. Bon, déjà
j'ai pas fait make-kpkg clean. Pas
bien. Enfin, les flavour c'est pour faire des
sous-sous-versions de noyaux incompatibles (notamment
vis-à-vis des modules) et les revision c'est
pour les paquets Debian.
Moi je veux juste avoir un noyau de même version compilé
avec d'autres options. Logiquement je ne sais pas, pffff, je
vais faire ça à la main et puis c'est tout. make
clean, make dep,
make bzImage. Quoique…
Bon, finalement je crois qu'il fallait que j'utilise une
revision supérieure après un make-kpkg
clean. Oups, je crois que mes problèmes venaient
de l'oubli du paramètre kernel_image. Donc,
make-kpkg --revision=marc.1.2
kernel_image. C'était bien cela ! En
revanche je vais faire la dernière étape à la main car je
veux que mon ancien noyau reste celui par défaut. Enfin
partiellement à la main, car il faut bien que j'utilise
dpkg pour installer le
kernel-image-2.2.19_marc.1.2_i386.deb
produit.
dpkg -i kernel-image-2.2.19_marc.1.2_i386.deb
(Reading database ... 48297 files and directories currently installed.)
Preparing to replace kernel-image-2.2.19 marc.1.1 (using kernel-image-2.2.19_marc.1.2_i386.deb) ...
You are attempting to install a kernel image (version 2.2.19)
However, the directory /lib/modules/2.2.19 still exists.
If you have deselected some modules, this could be bad.
You are attempting to install a kernel version that is the same as the version you are currently running (version 2.2.19). The modules list is quite likely to have been changed, and the modules dependency file /lib/modules/2.2.19/modules.dep needs to be re-built. It can not be built correctly right now, since the module list for the running kernel are likely to be different from the kernel installed. I am ccreating a new modules.dep file, but that may not be correct. It shall be regenrated correctly at next reboot.
Sâleté de chez saloperie, ça m'a écrasé mon précédent 2.2.19 et gardé cette vieille croûte de 2.2.18pre21. Pffff, zut, crotte, j'aurais mieux fait de tout faire à la main. Bon, je vais quand même prendre le risque de redémarrer avec le nouveau noyau, il est à peine différent.
Un peu chanceux, j'ai oublié de relancer LILO après avoir ajouté un délai. Mais la carte a été parfaitement détectée. Pour la suite des tests et de la configuration je verrai lorsqu'il y aura un autre PC au bout du câble.
ne2k-pci.c: v1.02 for Linux 2.2, 10/19/2000, D. Becker/P. Gortmaker, http://www.scyld.com/network/ne2k-pci.html ne2k-pci.c: PCI NE2000 clone 'RealTek RTL-8029' at I/O 0xd400, IRQ 12. eth0: RealTek RTL-8029 found at 0xd400, IRQ 12, 00:E0:7D:92:95:23.
Tout est allé pour le mieux du premier coup. Deux
commandes en tant que root et c'était bon :
ifconfig eth0 inet 169.254.31.122
puis route add net 169.254.0.0 netmask 255.255.0.0
dev eth0.
Il y a quelques mois, j'avais dû passer des heures à
rendre mon modem stable. À 56 kbits/s il était instable aussi
bien chez Sunrise
Freesurf que chez Infomaniak jusqu'à ce que je
trouve l'invocation magique +MS=11,1,300,33600.
Mais il semble que cette invocation ne soit pas nécessaire
chez Econophone.
Super, pourrais-je donc accélerer un peu mes
transferts ! Pour faire bonne mesure, je commence un
téléchargement du noyau 2.2.21. dctrl me donne
un débit plafonnant à 4000 octets/s, c'est pas encore
ça…
Tout arrive à point à qui sait attendre.
Voilà qui justifie la peine exceptionnelle d'une
installation dans /usr/local/. Pour être
précis, dans /usr/local/opt/mozilla/, à côté de
Star Office.
ls -l /usr/local/opt/
total 8
drwxrwsr-x 2 root staff 4096 Jun 5 23:27 mozilla
drwxrwsr-x 6 root staff 4096 Feb 16 2001 office52
Puis je suis les instructions : tar xzf
mozilla-i686-pc-linux-gnu-1.0-sea.tar.gz,
cd mozilla-installer/,
./mozilla-installer. Pour une fois,
j'installe tout. Tout semble s'installer tout seul,
chouette.
En revanche pour récupérer les courriers Netscape
Navigator ça risque d'être plus difficile. Le gestionnaire de
profil a été lancé tout seul. Mais comme j'ai laissé traîner
un vieux profil .mozilla et pas dupliqué mes
données, je quitte, je duplique, puis en tant que
marc au lieu de root comme
conseillé dans le README car j'ai installé en
tant que marc:staff, j'ajoute
/usr/local/opt/mozilla au PATH puis
je lance mozilla.
You know what? I am happy.
Le profil Netscape 4 a été converti automatiquement, puis
la fenêtre de Mozilla
s'est ouverte sur http://www.mozilla.org/start/1.0/.
Les release
notes prétendent que pour rendre Mozilla
multi-utilisateur sur Unix il faut exécuter le script suivant
en tant que root :
#!/bin/sh
dist_bin=`dirname $0`
MOZILLA_FIVE_HOME=$dist_bin
LD_LIBRARY_PATH=$dist_bin
export MOZILLA_FIVE_HOME LD_LIBRARY_PATH
$dist_bin/regxpcom
$dist_bin/regchrome
touch $dist_bin/chrome/user-skins.rdf $dist_bin/chrome/user-locales.rdf
J'ai créé le script mais j'hésite à le lancer, en effet,
tout fonctionne bien avec deux utilisateurs tout à fait
différents sans cela. (Le 27 juin j'ai découvert dans
poste sur Google que ce script servirait simplement à
éviter de lancer tout Mozilla en tant que root
pour le mettre en place.)
Ô joie, ô félicité, j'ai aussi pu importer, recevoir et envoyer mon courrier sans peine. Il me reste à installer des plug-ins multi-utilisateurs. Le plug-in Java est malheureusement un peu gros pour cette nuit.
LC_CTYPEIl y a quelques jours, j'ai remarqué que Mozilla 1.0 n'était pas capable
d'afficher les caractères non ASCII. Après avoir créé le
bug
150958, en lisant le
commentaire 90 du bug 9449 j'ai eu l'idée de donner une
valeur à LC_CTYPE : export
LC_CTYPE=fr_CH. Grâce à cela Mozilla est (à
nouveau) capable d'afficher les caractères ISO-8859-1 8 bits
dans le titre de la fenêtre. Et le même réglage permet au
programme less d'afficher les caractères non
ASCII !
Je décide donc de fixer la valeur de LC_CTYPE
dès que possible lors du lancement du système. Reste à
trouver le meilleur endroit. D'abord je pensais analyser les
scripts d'initialisation pour trouver le meilleur endroit,
puis je me suis dit qu'il y avait forcément un fichier séparé
conçu exprès pour contenir la définition idoine. J'ai trouvé
la réponse dans le
debian-fr-howto. Le fichier idoine est /etc/environment.
Il semble que se soit le module pam_env.so de
login qui lise ce fichier. J'aurai pu analyser
longtemps…
Mais évidemment il y a un hic, XDM n'utilise pas /etc/environment.
Le
manuel conseille de mettre LANG=french au
début du fichier ~/.xsession. N'ayant pas de
~/.xsession et ne voulant que
LC_CTYPE=fr_CH, je vais déjà essayer uniquement
avec /etc/environment.
La modification précédente n'ayant comme prévu pas suffit,
j'ajoute la ligne DisplayManager.exportList:
LC_CTYPE=fr_CH dans le fichier /etc/X11/xdm/xdm-config.
Mais ça ne fonctionne pas, comme si je n'avais rien
fait !
Rien à faire avec DisplayManager.exportList,
j'opte donc pour la solution simple : j'exporte
LC_CTYPE depuis /etc/bash.bashrc.
Je commence par un gros morceau : le JRE 1.4.0, 20 Mo
de téléchargement. Je lance le fichier téléchargé
j2re-1_4_0_01-linux-i586.bin qui installe tout
dans un répertoire j2re1.4.0_01. Je déplace ce
répertoire dans /usr/local/opt/java puis créé le
lien suivant :
ls -l /usr/local/opt/mozilla/plugins/
total 24
lrwxrwxrwx 1 marc staff 71 Jun 29 13:46 libjavaplugin_oji140.so -> /usr/local/opt/java/j2re1.4.0_01/plugin/i386/ns610/libjavaplugin_oji.so
-rwxr-xr-x 1 marc staff 19396 May 29 19:17 libnullplugin.so
Cela semble suffire pour que tout fonctionne. Évidemment Mozilla + Java avec 64 Mo ça ne donne rien de très intéressant. Rien que pour charger le Java(tm) Plug-in Control Panel, près de 40 Mo sont swappés sur le disque !
La mise de sécurité d'aujourd'hui est plus complexe que
d'habitude. Deux paquets sont mis à jour
(fetchmail et ssh) et un nouveau
paquet (libssl0.9.6) est installé. En outre la
mise à jour de Ssh cause l'ouverture de dialogues
d'avertissement :
ssh2 keys merged in configuration files
As of version 3 OpenSSH no longer uses separate files for ssh1 and ssh2 keys. This means the authorized_keys2 and known_hosts2 files are no longer needed. They will still be read in order to maintain backwards compatibility
This version of OpenSSH has a considerably changed configuration file from the version shipped in Debian 'Potato', which you appear to be upgrading from. I can now generate you a new configuration file (/etc/ssh/sshd.config), which will work with the new server version, but will not contain any customisations you made with the old version.
Please note that this new configuration file will set the value of 'PermitRootLogin' to yes (meaning that anyone knowing the root password can ssh directly in as root). It is the opinion of the maintainer that this is the correct default (see README.Debian for more details), but you can always edit sshd_config and set it to no if you wish.
It is strongly recommended that you let me generate a new configuration file for you.
Generate new configuration file
This version of OpenSSH supports version 2 of the ssh protocol, which is much more secure. Disabling ssh 1 is encouraged, however this will slow things down on low end machines and might prevent older clients from connecting (the ssh client shipped with "potato" is affected).
Also please note that keys used for protocol 1 are different so you will not be able to use them if you only allow protocol 2 connections.
If you later change your mind about this setting, README.Debian has instructions on what to do to your sshd_config file.
Allow SSH protocol 2 only
J'ai toujours répondu oui. Tout se déroule bien :
Installing new version of config file /etc/ssh/ssh_config ... Installing new version of config file /etc/init.d/ssh ... Installing new version of config file /etc/pam.d/ssh ... Creating SSH2 RSA key Creating SSH2 DSA key OpenBSD Secure Shell server not in use (/etc/ssh/sshd_not_to_be_run)
N'utilisant plus Apache, ni Junkbuster (ne supporte pas HTTP/1.1 de Mozilla) et n'ayant jamais essayé WWWOFFLE, j'ai de quoi nettoyer.
update-rc.d -f apache remove et
/etc/init.d/apache stop.dpkg -r
junkbuster qui me garde les fichiers de
configuration dans /etc/junkbuster/.
diald :
dpkg -P wwwoffle
(Reading database ... 48470 files and directories currently installed.)
Removing wwwoffle ...
150 ? S< 0:00 /usr/sbin/diald
Stopping HTTP cache proxy server: wwwoffled.
dpkg - warning: while removing wwwoffle, directory `/var/cache/wwwoffle' not empty so not removed.
dpkg - warning: while removing wwwoffle, directory `/usr/share/wwwoffle/html' not empty so not removed.
dpkg - warning: while removing wwwoffle, directory `/usr/share/wwwoffle' not empty so not removed.
dpkg - warning: while removing wwwoffle, directory `/etc/wwwoffle' not empty so not removed.
Purging configuration files for wwwoffle ...
find: /usr/share/wwwoffle: No such file or directory
find: /usr/share/wwwoffle: No such file or directory
Heureusement diald semble toujours aussi
bien fonctionner et il ne reste qu'un lien symbolique
/etc/wwwoffle/debian-replacement-image.gif
que j'efface par rm -r
/etc/wwwoffle.
Avec deux jours de retard, j'apprends sa sortie. Il ne me
reste plus qu'à lancer un dernier apt-get
update&&apt-get -u dist-upgrade pour
Potato avant d'entammer un
nouveau document sur le passage à Woody.
J'ai déjà commandé les CD de la nouvelle version à www.debian.ch…
© 2001, 2002, 2003, 2004, 2005, Marc
Mongenet
Ce document est disponible selon les termes de la Creative Commons Attribution 2.5 License.
Dernière mise à jour et
validation le 30 décembre 2017.