Je partirai du principe que le lecteur est déjà familiarisé avec la
compilation des noyaux de la famille 2.4.x « à l’ancienne ».

Bien que ce que je présente dans ce guide se soit assez bien passé pour moi, je ne peux que très vivement recommander de faire une sauvegarde complète du système avant de commencer, surtout si la configuration de la machine sort un tant soit peu de l’ordinaire.

Le noyau 2.6 est encore en béta version, et il est à craindre que les drivers de certains périphériques peu courants n’aient pas encore été beaucoups testés.

1/ La compilation.

La dernière version du noyau peut-être récupérée sur Le package update:

Si ce package est présent (dpkg -l | grep update pour vérifier), il provoquera un avertissement [[warning: process `update’ used the obsolete bdflush system call. Fix your initscripts ?]] pendant la phase d’init. Ce package est obsolète depuis la sortie du noyau 2.2.8 et peut-être supprimé.

Clients NFS:

Par défaut, /etc/init.d/nfs-common lance le démon lockd. Avec un kernel récent, c’est inutile (lockd est lancé automatiquement au montage d’un volume nfs). Avec le noyau 2.6, ça a provoqué un message d’erreur [[lockdsvc: function not implemented] »>http://www.kernel.org à l’init. Ce message est inoffensif. Pour éviter ce désagrément, il suffit de positionner la variable NEED_LOCKD à no au début du script nfs-common.

Pour s’assurer que le lancement de lockd à l’init n’est pas nécessaire, il suffit de faire un test. Si avec un nfs-common modifié un ‘ps aux’ fait apparaître une ligne [lockd »>ici après montage d’un volume nfs, ce script peut-être modifié sans risque.

Conclusion:

Il est encore un peu tôt pour que je me prononce sur ce noyau. Seul mon 486 tourne régulièrement avec le noyau 2.6 (contre toute attente, tous les drivers nécessaires à son bon fonctionnement avaient été portés).

Les résultats préliminaires sont plutôt encourageant. Le seul problème que j’ai eu à déplorer en 2 semaines d’utilisation est un freeze complet de la machine intervenu après une semaine et demie de fonctionnement continu et sans le moindre incident.

Compte tenu du caractère pour le moins exotique de la plate forme de test, ce n’est pas si mal pour un noyau qui est encore en béta version.

Je pense que tous les utilisateurs de debian font la même chose:

soif@inspiron:~$ apt-cache search fluxbox
fbdesk - desktop icons for fluxbox window manager
fluxbox - Highly configurable and low resource X11 Window manager
fluxconf - FluxBox configuration utility
soif@inspiron:~$ apt-get install fluxbox


Pourqoi le faire en 2 opérations alors qu’il existe apt-iselect ?

Voici un petit utilitaire qui peut parfois dépanner. Afin d’expliquer son fonctionnement je vais prendre un exemple:

Il y a peu de temps, je me suis trouvé face à un dilemme, je devait télécharger à partir du ftp.freebsd.org les ISO de la dernière version. Jusque là rien de grave, sauf que cela faisait 3 ISOs de 650 Mo sur ma connection ADSL. De plus je n’avais pas envie de bloquer tout les autres téléchargements avec ces 3 ISOs. N’ayant jamais réussi à installer une Qos (qualité de service) décente sur ma passerelle, je me suis retrouvé confronté à un problème: Le téléchargement des ISO utilisait toute la bande passante, et mes nombreux ssh devenait inutilisables. Après 3 sec de réflexion, je me suis rappelé que j’avais vu qque part un « userland shaper » à savoir tickle. Après quelques tests, j’ai trouvé ca très pratique et j’ai donc décidé de vous le faire partager. Le principe est le suivant, trickle lance le logiciel donné en lui faisant croire que le max de bande est égale a ce que vous avez mis:

Voici qques exemples :


# force ncftp à n'utiliser que 10Ko/s max lors du téléchargement
$trickle -d 10 ncftp ftp.freebsd.org

# idem avec wget
$trickle -d 10 wget http://linuxfr.org/


Intéressant non ? 🙂

Introduction

Ce court tutoriel à pour but de permettre d’installer un serveur imap SSL sur une machine (typiquement une passerelle ADSL) afin de rendre les mails accèssibles de l’extérieur de manière sécurisé.

Qui n’a jamais était confronté au problème suivant:
Comment lire au boulot mes mails que j’ai récupéré à la maison ?
Comme ne pas avoir tous les mails en double ( par ex en les lisant et en les renvoyant vers une autre adresse ) ..

Une méthode consiste à accéder à vos mails sur votre machine perso via ssh + un lecteur de mail en mode texte par ex mutt. Mais cela peut poser des problèmes comme par exemple comment transféré des mails du boulot vers votre compte email perso .. etc etc.

Mais la méthode exposé ici est bcp + pratique car elle permet :
– de travailler tout le temps sur la même arborescence de messagerie
– de changer facilement de lecteur de mail (mozilla / evolution / outlock etc etc ) car les mails sont sauvegardés sur le serveur et non pas dans le client de messagerie lui même.

La solution retenue est basé sur :
– postfix
– procmail
– courier-imap-ssl

Comment ca fonctionne ?

Afin d’arriver à nos fins il faut que les mails soit récupérés des différents serveurs de mails pop chez wanadoo free … etc centraliser dans une boite à lettre commune (cette partie était faite via fetchmail / procmail ). Et ensuite configurer le serveur imap pour utiliser cette boite à lettre.

Récuperation des mails:

Pour la récupération des mails nous allons utiliser fetchmail en mode démon.

apt-get install fetchmail procmail

Sur une debian il suffit de d’éditer le fichier /etc/fetchmailrc
afin que les mails sont récupérer de manière automatique.

voici un exemple :

poll pop3.club-internet.fr protocol POP3 user monlogin password XXX is test@localhost

Les mails seront donc « poper » de chez club-internet et transmis à test@localhost. Ceci via postfix mais cela peut être fait directement ou avec un autre SMTP (exim par ex)

Regroupement des mails:

Les mails ainsi « poper » vont donc être délivré à l’utilisateur test@localhost mais il faut qu’ils soient stockés dans un répertoire particulier à savoir /home/test/Maildir (répertoire par défaut de courier-imap). Dans ce but nous allons utiliser procmail.
Poour cela il faut :
– créer le répertoire /home/test/Maildir à l’aide de la commande maildirmake /home/test/Maildir
– configurer postfix pour utiliser procmail en ajoutant la ligne
mailbox_command = procmail -a « $EXTENSION »
dans le fichier /etc/postfix/main.cf
– configurer procmail afin qu’il délivre les mails dans /home/test/Maildir à l’aide du fichier .procmailrc


MAILDIR=$HOME/Maildir/
DEFAULT=$MAILDIR
LOGFILE=$HOME/.from
LOCKFILE=$HOME/.lockmail


attention le / à la fin est important il stipule à procmail que la boite a lettre en question est de type ‘Maildir’ et non pas mbox comme par défaut.

Premier tests

il suffit d’envoyer un mail à l’utilisateur test@localhost via la commande « mail » afin de vérifier que le mail se trouve ensuite dans le fichier /home/test/Maildir/new/xxxxxxxxxxx.

Ensuite on teste en rajoutant le fetchmail. Une fois que cette partie la est opérationnel il suffit d’installer le serveur courier-imap-ssl (via le paquet officiel de votre distribution). Au moment de l’installation ce dernier devrait vous générer un certificat SSL et démarrer.

Lecteur de mails

Il ne reste plus qu’à configurer votre lecteur de mail afin qu’il connaisse ce nouveau compte mail. Quasiment tout les clients de mail permettent d’utiliser imap.
Pour mozilla il suffit de créer un compte mail, et type de serveur imap, login test, password le mdp de test ( surtout n’oublier pas de dire que la connection est sécurisé) et c’est fini 🙂

Astuces

Une astuce consiste aussi d’utiliser procmail pour trier les mails dans différente répertoires . Pour cela il suffit de créer ces répertoires via votre lecteur de mail et rajouter des rêgles dans le fichier .procmailrc comme par exemple


:0
* ^From.*@respyre.org
.respyre/


qui aura pour effet de stocker les mails venant de respyre.org dans le répertoire /home/test/Maildir/.respyre/new/
( Attention au .respyre en effet courier imap utilise les . comme séparateur de hierarchie, ainsi donc le répertoire News/BSD ce traduit par un répertoire en Maildir/.News.BSD/