Ma carte graphique est une Siluro GF4 Ti. Le chipset est un NVIDIA GeForce4 Ti 4200 fonctionnant à 250MHz avec 64Mo de mémoire.
Le module nv de XFree86 fourni avec la Woody ne fonctionne pas avec cette carte. Il faut utiliser le driver nvidia disponnible, sous forme de source, sur le site de NVIDIA. Il se présente sous la forme de deux paquets tar.gz : NVIDIA_GLX-1.0-xxxx.tar.gz et NVIDIA_kernel-1.0-xxxx.tar.gz. Personnellement, j'ai utilisé les versions 2960.
Compilation Adaptation des includes Changement de noyau
L'activation se fait avec X :1 -layout Twin.
D'après mon expérience (je n'ai pas vérifié si c'est normal ou pas) il faut avoir branché le cable composite avant d'activer ce serveur X sinon cela ne fonctionne pas. |
Il s'agit d'une Sound Blaster Live 5.1.
Le module est emu10k1.
Une fois le fichier créé, il ne reste qu'à mettre à jour /etc/modules.conf avec update_modules.
Après quelques tests, le module ne semble pas se charger lors d'une requète. J'ai donc ajouté une ligne contenant snd dans le fichier /etc/modules.
hercules:~# hdparm -V hdparm v4.5 hercules:~# hdparm /dev/hdc /dev/hdc: HDIO_GET_MULTCOUNT failed: Invalid argument I/O support = 1 (32-bit) unmaskirq = 1 (on) using_dma = 0 (off) keepsettings = 0 (off) HDIO_GET_NOWERR failed: Invalid argument readonly = 1 (on) readahead = 8 (on) HDIO_GETGEO failed: Invalid argument busstate = 1 (on) hercules:~# hdparm -d1 /dev/hdc /dev/hdc: setting using_dma to 1 (on) HDIO_SET_DMA failed: Operation not permitted using_dma = 0 (off) hercules:~# hdparm -d1 -X34 /dev/hdc /dev/hdc: setting using_dma to 1 (on) HDIO_SET_DMA failed: Operation not permitted setting xfermode to 34 (multiword DMA mode2) Segmentation fault hercules:~# hdparm -d1 -X66 /dev/hdc /dev/hdc: setting using_dma to 1 (on) HDIO_SET_DMA failed: Operation not permitted setting xfermode to 66 (UltraDMA mode2) Segmentation fault
Suite à l'installation, le graveur est utilisable en lecteur uniquement.
Une fois le fichier créé, il ne reste qu'à mettre à jour /etc/modules.conf avec update_modules.
J'utilise gtcd pour lire les CD, grip pour ripper et encoder. Par contre, afin que ces deux utilitaires utilisent la même BD locale pour les infos CDDB, j'ai fait un lien entre ~/.cddb (utilisé par grip et ~/.cddbslave.
On a besoin du client : apt-get install ntpdate
Il faut faire en sorte que le client est lancé lors de chaque connection. Pour ce faire, on rajoute un script dans /etc/ppp/ip-up.d. Mon script est présenté en Exemple 5
Le package 'pon' est parfait. Il se configure avec pppconfig. La connexion est activée avec un simple pon et est fermée avec un simple poff. Pour que cela fonctionne, il faudra que chaque utilisateur pouvant activer le lien PPP soit déclaré dans le groupe 'dip'.
L'intérèt de ce package, c'est qu'il est tellement simple que n'importe qu'elle applet de gestion du lien PPP pourra être configurée pour utiliser les deux commandes pon et poff.
IpTables
Rejet de tout ce qui rentre : ma machine n'est pas un serveur.
iptables -A INPUT -i ppp0 -j DROP
Ca c'est trop draconien : y'a plus rien qui marche coté Internet.
Le package 'exim' s'installe très facilement. Il se configure à l'installation ou avec la commande eximconfig. Le type de connexion qui nous interesse est appelée smart host.
Le package 'fetchmail' est un incontournable, surtout sa version daemon (/etc/init.d/fetchmail). Il gère parfaitement les multipop (il est très fréquent aujourd'hui que chacun dispose de plus d'une adresse email) ainsi que l'aspect multi-utilisateur (chaque membre de la famille peut avoir un compte sur la machine et voir son courrier perso déposé sur son compte).
En ce qui concerne les réglages, la première configuration peut être assistée à l'aide de l'outil fetchmailconf (dans le package du même nom). Cette configuration doit être enregistrée sous /etc/fetchmailrc pour pouvoir utiliser la version daemon (cf. /etc/init.d/fetchmail). Par contre, la syntaxe du fichier de configuration étant très simple, il est préférable de faire les réglages suivant sous éditeur de texte.
Par défaut, le daemon fetchmail se retrouve systématiquement actif. Pour optimiser et éviter un éventuel comportement étrange, il est possible d'améliorer le processus. Ainsi, on va bricoler un peu pour que le daemon fetchmail ne soit actif que lorsque la connexion PPP l'est. Pour ce faire, il faut s'assurer que ce service n'est plus démarré au boot (Exemple 6) et modifier les fichiers /etc/ppp/ip-up.d/fetchmail (Exemple 7) et /etc/ppp/ip-down.d/fetchmail (Exemple 8).
Le plus simple à utiliser est 'sitecopy'. Cet utilitaire détecte tout seul les fichiers que vous avez modifiés. Il ne transfère que ces fichiers.
Pour ne pas avoir à redonner son mot de passe à chaque session, il suffit de le mettre dans le fichier ~/.netrc (cf. man netrc). |
Ma consommation Internet depuis chez moi est assez faible (une dixaine d'heure par mois). Ce type de consommation me fait étudier des solutions de type consommation à la minute ou mini-forfait (le Haut débit est vraiment inutile). Sur ce marché, les fournisseurs d'accès se font une guerre ouverte. Les prix pouvant changer rapidement, il faut donc se préparer à changer souvent de FAIs.
En plus, avec ce type de connexion, il n'est pas rare de trouver la ligne occupée ou de rencontrer des difficultés d'établissement de la ligne. Il est donc bien pratique de pouvoir basculer immédiatement vers un autre FAI.
Le package 'ppp' sait travailler avec plusieurs connexions. Il suffit de rajouter une connexion depuis pppconfig.
L'activation se fait toujours avec pon. Sans argument, cette commande active la connexion de nom provider. Pour activer une autre connexion, il suffit de rajouter son nom en argument : pon no-log.
Voici un sujet bien plus délicat.
En effet les FAIs semblent refuser les connexions sur leurs SMTP si la demande ne provient pas de leur réseau (sécurité de base et donc probablement efficace vis à vis des spammeurs). Du coup, il faut trouver une configuration ou 'exim' change tout seul de smtp en fonction de la connexion en cours.
Pour l'instant, votre fichier /etc/exim/exim.conf doit contenir les lignes suivantes :
# Send all mail to a smarthost smarthost: driver = domainlist transport = remote_smtp route_list = "* smtp.fai.fr bydns_a" end
À la lecture de la documentation (package 'exim-doc'), on doit pouvoir obtenir l'effet escompté en remplaçant la ligne route_list par
route_list = "* smtp.fai1.fr:smtp.fai2.fr bydns_a"
Ceci n'est pas vraiment satisfaisant (puisqu'il faut mettre se fichier à jour aussi) mais pour l'instant je n'ai pas essayé autrement.
J2re récupéré sur un CD Login.
Liens symboliques :
cd /usr/lib/mozilla/plugins ln -s /opt/java/j2re1.4.1_01/plugin/i386/ns600/libjavaplugin_oji.so . cd /usr/lib ln -s libstdc++-3-libc6.2-2-2.10.0.so libstdc++-libc6.1-1.so.2
apt-get install kernel-source-2.4.18 cp /boot/config-... .config make menuconfig make-kpkg --initrd --append_to_version=-guyou --revision=1 kernel_image
Il s'agit d'un produit avec une connectique USB.
vendor 0x040a product 0x0570
Installation hotplug. La doc de gphoto2 fait référence à hotplug. Comme on le vera par la suite, ce dernier est responsable de quelques configurations à chaud indispensables. apt-get install hotplug
Réglages. Les réglages assurés par hotplug consistent à fournir les bons droits sur le device de l'appareil photo. Pour ce faire, il faut créer le script /etc/hotplug/usb/usbcam. Comme source pour ce programme, et contrairement à ce que dit la documentation gphoto2 je choisi le fichier /usr/share/doc/gphoto2/linux-hotplug/usbcam.group. En effet, le fichier /usr/share/doc/gphoto2/linux-hotplug/usbcam.console risque de ne pas fonctionner sous Debian car la console (/dev/console) n'a que très peu de droits. De plus, utiliser un groupe camera semble assez bien dans la logique Debian. Il faut ensuite lui donner les droits qui conviennent : chmod a+x /etc/hotplug/usb/usbcam Afin que ce script soit exécuté à la connexion de l'appareil photo, il faut l'indiquer à hotplug. Ceci se fait avec la commande suivante :
Gestion du group. Il faut d'abord le créer : addgroup camera. Ensuite, il faut ajouter les utilisateurs sur la ligne camera: du fichier /etc/group. Une déconnexion/re-connexion de l'utilisateur est alors nécessaire pour prendre en compte cette modification.
Fournisseur d'accès Internet