Notes Debian

[...]

Section "Device"
	Identifier "TwinViewTV2"
	Driver "nvidia"
	BusID "PCI:1:0:0"
        Option "TwinView"
        Option "SecondMonitorHorizSync"   "30-50"
        Option "SecondMonitorVertRefresh" "60"
        Option "TwinViewOrientation"      "Clone"
        Option "MetaModes"                "800x600,800x600"
        Option "TVStandard"	          "PAL-N"
        Option "TVOutFormat"	          "COMPOSITE"
EndSection

Section "Monitor"
        Identifier      "TV"
        HorizSync   30-50
        VertRefresh 50-70
EndSection

Section "Screen"
    Identifier  "TwinViewTV2"
    Device      "TwinViewTV2"
    Monitor         "TV"
    DefaultDepth 24
    Subsection "Display"
        Depth       24
    EndSubsection
EndSection 

Section "ServerLayout"
	Identifier	"Twin"
	Screen		"TwinViewTV2"
	InputDevice	"Generic Keyboard"
	InputDevice	"Configured Mouse"
	InputDevice	"Generic Mouse"
EndSection

[...]
	  

L'activation se fait avec X :1 -layout Twin.

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
	

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.

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, « Suppression du démarrage de fetchmail au boot ») et modifier les fichiers /etc/ppp/ip-up.d/fetchmail (Exemple 7, « /etc/ppp/ip-up.d/fetchmail ») et /etc/ppp/ip-down.d/fetchmail (Exemple 8, « /etc/ppp/ip-down.d/fetchmail »).

/root# cd /etc
/etc# mv -i rc2.d/S99fetchmail rc2.d/K15fetchmail
/etc# mv -i rc3.d/S99fetchmail rc3.d/K15fetchmail
/etc# mv -i rc4.d/S99fetchmail rc4.d/K15fetchmail
/etc# mv -i rc5.d/S99fetchmail rc5.d/K15fetchmail
            

[ $PPP_IFACE = ppp0 ] && /etc/init.d/fetchmail start 2>&1 | logger -p mail.info

[ $PPP_IFACE = ppp0 ] && /etc/init.d/fetchmail stop 2>&1 | logger -p mail.info

Utilisation du paquetage leafnode.

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.

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.

# Send all mail to a smarthost

smarthost:
  driver = domainlist
  transport = remote_smtp
  route_list = "* smtp.fai.fr bydns_a"

end
            

  route_list = "* smtp.fai1.fr:smtp.fai2.fr bydns_a"