Dupnet weblog

Eh oui le spam est à la mode en ce ce moment (avec 75% de messages spam sur internet), bien que ce soit une mode forcée, effectivement c'est rarement par choix que l'on reçoit ces inombrables pubs (anglophone pour la plupart) dans notre boîte aux lettres virtuelle.

Ne faisant pas exception j'ai vu le nombre de spam dans ma boîte de réception grossir et je me suis enfin décidé à ajouter une solution de filtrage à mon postfix adoré en utilisant le célèbre SpamAssassin.

Dans un premier temps il faut donc installer SpamAssassin sur votre distribution, par exemple sous gentoo, il suffit de taper la commande suivante :

emerge -av spamassassin

Une fois SpamAssassin installé, par précaution, sauvegarder maintenant votre configuration postfix, on sait jamais une bétise est vite arrivé, vous voilà prévenu !! Par exemple avec un "tar cvf ~/backup_postfix.tar /etc/postfix" Une fois ceci fait, éditer le fichier master.cf (par défaut il est situé dans /etc/postfix) et modifier la ligne concernant smtp de la manière suivante :

smtp      inet  n       -       n       -       -       smtpd -o content_filter=spamfilter:dummy

Cette ligne demande à postfix d'appeler le filtre spamfilter lors de la réception d'un mail en SMTP, il faut donc aussi ajouter la ligne suivante au fichier master.cf :

spamfilter unix  -       n       n       -       -       pipe flags=Rq user=spamfilter argv=/usr/bin/spamfilter -f ${sender} -- ${recipient}

La ligne ci-dessus déclare le filtre spamfilter qui sera invoqué lors de la réception d'un mail, et exécutera le script /usr/bin/spamfilter avec le compte utilisateur spamfilter (le créer au besoin avec comme shell /bin/nologin).

Voila c'est tout pour la configuration de postfix, si vous regardez sur votre système de fichier, le script /usr/bin/spamfilter n'existe pas, nous allons le créer avec le contenu suivant :

#!/bin/sh

/usr/bin/spamc | /usr/sbin/sendmail -i "$@"

exit $?

Ce script appelle tout simplement le client spamassassin spamc pour traiter le mail (ajout de ****SPAM**** dans l'objet du message, ou encore les X-Headers dans l'entête du mail), puis invoque la commande sendmail pour délivrer le mail.

Voila la configuration est terminée, il nous reste à lancer le démon SpamAssassin et recharger la configuration de Postfix :

/etc/init.d/spamd start
postfix reload

Voilà notre filtrage est en place, j'ai controlé que tout fonctionnait bien à l'aide du "tail -f /var/log/messages" pour afficher les évènements en temps réel. Il ne reste plus qu'a vous envoyer un mail depuis l'extérieur, regarder qu'au niveau des logs tout est bon, pour ensuite sous votre client messagerie préféré regarder l'entête du message (Ctrl+U sous Thunderbird) afin de voir les champs X-Spam-Flag, X-Spam-Level par exemple.

Si SpamAssassin marche correctement, il ne vous reste plus qu'à ajouter le lancement de SpamAssassin au démarrage de votre poste via la commande suivante :

rc-update add spamd default

Ah oui j'oubliais, vous pouvez ajuster le comportement de SpamAssassin via le fichier /etc/spamassassin/local.cf, notamment les listes blanches/noires.

Liens utiles :

Site officiel de postfix Site officiel de SpamAssassin Tutoriel en anglais

Ajaxterm est un outil bien pratique puisqu'il permet d'obtenir un terminal fluide et en couleur via une interface web. Seulement voilà Ajaxterm ne fonctionne pas en HTTPS ainsi toute tentative de connexion passe en clair entre le client web et le serveur Ajaxterm.

Ainsi l'auteur conseille d'utiliser le module proxy d'apache 2 pour se sécuriser via SSL. Seulement j'utilise lighttpd en lieu et place d'Apache (plus souple, plus simple, rapide et suffisant pour mes besoins) et là il faut chercher un peu pour obtenir une configuration idéale.

Possédant une gentoo, l'installation d'ajaxterm s'effectue tout simplement via un : "emerge ajaxterm". A la suite de ça, il va falloir modifier le script qui lance Ajaxterm au démarrage (après avoir fait au préalable un rc-update add ajaxterm default) et ajouter l'option "--command="ssh -l <monuser> localhost"" au lancement du démon Ajaxterm. En effet Ajaxterm se comporte mal avec le login habituel, on a la mirre de connexion "Login :", mais le mot de passe nous est jamais réclamé. En utilisant ssh comme moyen de connexion on passe outre ce problème mais oblige à définir l'utilisateur avec lequel on va se connecter au système.

Ensuite il faut ajouter à la configuration de lighttpd les lignes suivantes pour faire office de proxy à Ajaxterm :

$HTTP["host"] == "adresse_de_mon_serveur_ajaxterm" {
                proxy.server = ( "" =>
                        ( ( "host" => "127.0.0.1", "port" => 8022 ) )
                )
}

==> Cela permet de passer lighttpd en proxy (mod_proxy dans le fichier de configuration à activer) pour Ajaxterm qui tourne sur l'adresse 127.0.0.1 et port 8022 (par défaut)

Afin de sécuriser le tout on va passer une couche de SSL pour avoir du HTTPS

$SERVER["socket"] == ":443" {
        protocol = "https://"
        ssl.engine    = "enable"
        ssl.pemfile   = "/etc/ssl/lighttpd/lighttpd.pem"
}

• note : a vous de créer votre fichier pem pour votre serveur, la documentation est disponible sur le site officiel de lighttpd => http://www.lighttpd.net

Reste à utiliser le module redirect (mod_redirect) de lighttpd pour renvoyer tout traffic HTTP (port 80) vers l'équivalent HTTPS (port443)

$SERVER["socket"] == ":80" {
       $HTTP["host"] =~ "(.*)" {
                url.redirect = ( "^/(.*)" => "https://%1/$1" )
        }
}

On relance les services et voilà un Ajaxterm tout beau sous lighttpd et sécurisé via SSL.

Plutôt que rediriger tout le traffic HTTP vers HTTPS on aurait tout aussi bien pu utiliser le SSL pour Ajaxterm (chose que j'avais fait au départ mais qui correspond moins à mes besoins).

Voila à vous de jouer.

Comme promis je rapatrie l'article sur le packaging de VNC en fichier msi.

Voilà, créer un package MSI du célèbre logiciel VNC n'est pas simple, en effet nombre post sur les forums ou mailing list ont été écris afin de savoir comment créer un package MSI de VNC. Ou je travaille, Netmeeting est installé pour la prise de main à distance par le service hotline micro, seulement avec le temps il s'avère que sur de plus en plus de postes Netmeeting ne fonctionne plus, privant ainsi le service du contrôle des PCs à distance (et faut bien avouer que netmeeting n'est pas à proprement parler un logiciel de contrôle à distance). De plus actuellement une migration d'un domaine NT4 vers un domaine 2003 est en cours et c'est via les GPOs de Windows 2003 que nous voulons déployer un nouveau logiciel de prise de main à distance. Seulement RealVNC ne fournit qu'un exécutable en guise d'installation et Windows 2003 ne gère que les fichiers MSI. Ainsi en couplant 2 logiciels il s'avère possible de créer une installation de VNC déployable via les GPOs Windows 2003 et donc conforme au format MSI.

Etape 1 :

Comme beaucoup de monde je suis parti du logiciel WinstallLE fournit en standard sur tout CD de Windows 2000 Pro. Ce logiciel permet permet de créer des packages MSI de "n'importe" quel logiciel. Pour ce faire il faut lancer WinstallLE Discover qui va créer ce qu'il appelle le "snapshot before" qui correspond à l'état du PC avant l'installation du logiciel qu'on veut packager. Ensuite on installe notre logiciel et on relance WinstallLE Discover qui va générer un "snapshot after" afin d'analyser toutes les différences avec le "snapshot before", et ces différences correspondent tout simplement à l'ajout de notre logiciel : VNC. Dans le fonctionnement, WinInstallLE génère un fichier .NAI (propre à WinInstall) puis convertis ce fichier en package MSI. Seulement voilà avec VNC, le processus bloque lors de la conversion du fichier NAI en package MSI avec un message spécifiant qu'il ne peut trouver l'exécutable WinVNC4 -service. Bug du logiciel qui interprète l'argument passé à VNC comme étant le programme lui même. Solution éditer le fichier NAI généré par WinInstall dans votre éditeur de texte préféré, puis enlever l'argument "-service", sauvegarder et lancer WinInstallLE de nouveau, effectuer une conversion de notre fichier NAI fraichement modifié en package MSI et comme par magie on obtient notre paquet MSI valide et déployable (ou presque voir la suite).

Etape 2 :

En effet si on tente de déployer ce paquet, VNC va bien s'installer mais ne sera pas fonctionnel, en effet, ce paquet MSI crée un service VNC mais il ne faut pas oublier que nous avons supprimer l'argument "-service" au programme VNC, ainsi le lancement du service échoue. On va donc effectuer une modification sur notre paquet MSI avec le logiciel Orca MSI Editor. Ce logiciel est gratuit et fourni par Microsoft permet d'éditer différentes propriétés d'un paquet MSI. Ainsi avec Orca on va éditer notre package MSI et dans la section service, tout simplement ajouter dans la colonne argument "-service", on enregistre et on teste à nouveau notre package MSI.

Et la miracle, celui-ci s'installe correctement, crée un service Windows valide et enfin le démarrage du service fonctionne et réagit comme on le voulait. Seul bémol pour le moment je n'ai pas réussi a lancer le service automatiquement après l'installation, il faut soit redémarrer le PC ou démarrer le service à la main. Son mode de démarrage sinon est bien automatique, donc à chaque démarrage du PC le service démarre.

Voilà en espérant que ce petit tutoriel pour créer un package MSI du logiciel VNC vous servira, car moi aussi j'y ai passé un peu de temps avant d'avoir quelque chose que je pouvais déployer sur notre domaine Windows 2003.

Voilà après avoir fait un bref passage sur Dotclear2, je reviens sur la version 1. Pourquoi ce revirement, tout simplement car j'aime bien le thème personnalisé qu'une amie et moi avons réalisé pour Dotclear 1 plutôt que d'utiliser le thème par défaut de Dotclear2.

De plus je pense que Dotclear 1 comble largement mes besoins, il me reste à backporter mes articles de Dotclear2 concernant principalement le packaging de VNC (en fichier msi) et ainsi que celui sur la création de paquet pour Archlinux.

La FSF (Free Software Foundation) à déclaré ce jour comme la journée contre les DRM (Digitals Rights Management). En effet les DRM sont un danger pour l'avenir du logiciel et l'interoperabilité. Pourrais-je à l'avenir toujours lire mon fichier sur mon système d'exploitation favori ?

Pour plus d'info : StopDRM

Nouvelle mouture du serveur web avec les changements suivants

• redirection automatique vers dotclear lors de l'accès à la page Dupnet
• le serveur utilise maintenant SSL et les connexions sont ainsi chiffrées, l'accès sur le port 80 redirige automatiquement vers l'accès sécurisé
• changement du bandeau du site et début d'un thème personnalisé de dotclear, un grand merci à titnénuphar pour le bandeau

Après avoir découvert Dotclear sur un site, je me lance moi aussi dans l'aventure. Pas fan de blogs mais Dotclear a l'air conçu de tel sorte que l'on puisse y mettre un contenu conséquent qui va au delà du simple blog.