Hacky's blog

Configuration routage sur dedibox pro

hacky — Sun, 29 Mar 2009 20:51:00 +0200

Aie aie... Le dernier post sur ce blog date d'aout 2008... C'est honteux ! :(

Voici un petit quelque chose qui devrait ravir les utilisateurs de dedibox pro...

Ce serveur possède deux interfaces réseau et donc deux IP publiques. Chaque interface utilise une passerelle par défaut différente pour des raisons de sécurité. Or, par défaut, la configuration des interfaces est spéciale... Si vous établissez une connexion sur l'ip de la seconde interface réseau (eth1), le trafic sortant va intégralement passer par eth0 ! Pourquoi ? Et bien parce que dans la table de routage, la première passerelle par défaut est eth0 :)

Votre serviteur a une solution : jouer avec iproute pour faire comprendre au système comment router les paquets.

Commencez tout d'abord par installer le paquet iproute si ce n'est pas déjà fait :

# aptitude install iproute

Repérez vos deux IP ainsi que vos deux passerelles (les IP suivantes ont été choisies arbitrairement) :

# ifconfig | grep 'inet adr'
inet adr:88.191.88.2  Bcast:88.191.88.255  Masque:255.255.255.0
inet adr:88.191.90.2  Bcast:88.191.90.255  Masque:255.255.255.0
# route -n
88.191.88.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
88.191.90.0    0.0.0.0         255.255.255.0   U     0      0        0 eth1
0.0.0.0        88.191.88.1     0.0.0.0         UG    0      0        0 eth0
0.0.0.0        88.191.90.1     0.0.0.0         UG    0      0        0 eth1

Première étape, on crée deux tables de routage spécifiques, une pour chaque interface. Pour cela éditez le fichier /etc/iproute2/rt_tables avec votre éditeur favori, et ajoutez en fin de fichier les lignes suivantes :

88  pri
90  sec

Les nombres peuvent être définis à votre convenance, mais je trouve pratique de mettre ici l'avant dernier "bloc" de l'ipv4 pour se repérer.

Ensuite, téléchargez ce script : script de routage dedibox pro et placez le là où il vous chante, personnellement il est dans /etc/network :

# mv routes.sh.txt /etc/network/routes.sh
# chmod +x /etc/network/routes.sh

Editez ce script pour y faire figurer les IP de votre serveur. Pour cela changez les variables neteth0, ipeth0, gweth0, neteth1, ipeth1, gweth1. Si vous utilisez une ou plusieurs IP failover, décommentez la ligne 30 et adaptez le contenu.

Lancez ensuite ce script à chaque boot de serveur, via /etc/rc.local par exemple.

Lorsque vous effectuerez une connexion depuis le serveur vers l'extérieur, cette connexion sortira alternativement par eth0 ou eth1. Une demande de connexion depuis l'extérieur vers l'ip d'eth1 du serveur fera bien sortir le trafic par eth1, même topo pour eth0.

Elle est pas belle la vie ?

Nouveau serveur dedibox pro et benchs

hacky — Tue, 12 Aug 2008 14:23:00 +0200

Et bien comme en avril, on prend les mêmes et on recommence :)

Hmm, pas tout à fait, là dedibox s'attaque au haut de gamme avec un serveur surpuissant motorisé par un Quad Core Intel Xeon X3350, de 8Go de RAM ECC, de 2 disques d'1To en enregistrement perpendiculaire (3ème disque en option), de deux connexions 1Gb/s (2 interfaces réseau) pour 99,99 euros HT par mois !

J'en ai donc profité pour refaire le jeu de benchs que j'avais réalisé en avril pour la sortie des V2 et XL.

J'ai donc eu la chance de tester ce serveur en beta-test pendant une dizaine de jours. Concernant le cocktail CPU, RAM, disques, rien à redire ça galope très très vite...

La grande nouveauté pour du serveur loué c'est l'accès IPMI : cette technologie permet d'avoir complètement la main sur son serveur (power off, power on, état des capteurs, log d'éventuels problèmes matériels bas niveau, console série sur IP qui vous permet de suivre le boot complet du serveur et d'intervenir en cas de problème de configuration, etc...). Plus d'infos sur la documentation dedibox.

Pour avoir un petit aperçu des performances de cette dedibox pro, mon comparatif serveurs dédiés à été mis à jour.

Un autre betatesteur a effectué des benchs apache (effectués avec ab, redemarrage à chaque fois d'apache et 3min de pause entre chaque test) et mysql, les voici :

Pour résumer, c'est un serveur taillé pour de la virtualisation ou de l'hébergement d'applications gourmandes et hautement sensibles. A un tel prix, je pense qu'un concurrent en 3 lettres va accuser le coup...

Déménager son compte mail en IMAP

hacky — Wed, 16 Jul 2008 22:58:00 +0200

Voici une petite astuce qui pourra certainement vous éviter de longues recherches...

Vous avez besoin (comme moi aujourd'hui) de migrer le contenu d'un ou de plusieurs comptes e-mail en changeant de serveur ? Et bien il y a des gens bien qui ont pensé à vous en codant ce petit utilitaire appelé imapsync.

Imapsync vous permet de cloner de façon complète un compte IMAP (répertoires, sous répertoires inclus, état des messages...) vers un autre compte IMAP. Très pratique lorsqu'on désire faire un backup d'un compte ou alors effectuer une migration d'un compte mail depuis un serveur où on ne peut pas accéder au répertoire Maildir directement.

Il s'utilise de la façon suivante :

imapsync --host1 imap.domaine.com --user1 comptesource@domaine.com \
--host2 cible.domaine.com --user2 comptecible@domaine.com

J'ai trouvé une utilisation un peu détournée de la chose, mais assez pratique Vous pouvez sauvegarder votre Maildir vers gmail de cette façon :

imapsync --host1 imap.domaine.com --user1 adr@domaine.com \
--ssl2 --host2 imap.gmail.com --user2 machin@gmail.com \
--prefix2 INBOX.Backup. --authuser2 machin@gmail.com \
--authmech2 LOGIN --syncinternaldates

Panique en salle 12

hacky — Fri, 09 May 2008 09:54:00 +0200

Ça aurait pu faire un très bon titre pour un polar, mais non... On va parler un peu d'hébergement :)
D'où l'art de refroidir les serveurs chez OVH...

Depuis un petit mois j'ai une machine dédiée à du backup chez OVH, un serveur kimsufi reloaded 2008 faisant tourner essentiellement un bacula.
Pour quelques précisions, cela fait plus d'un an (mars 2007) que je loue un serveur dédié chez OVH, je suis passé d'un start100m à un superplan 2007, je n'ai maintenant plus que ce petit serveur de backup qui me rend de fiers services.

J'ai reçu mercredi 7 mai 2008 après midi des alertes de mon monitoring nagios m'indiquant un température excessive au niveau du disque dur :

# hddtemp /dev/sda
/dev/sda: HDT722525DLA380                          :  58°C ou °F

La carte mère n'est pas beaucoup mieux refroidie :

# sensors | grep Temp
Sys Temp:    +54.0°C  (high = +32.0°C, hyst = +16.0°C)  ALARM  
CPU Temp:    +48.0°C  (high = +110.0°C, hyst = +75.0°C)

Le serveur s'est planté en fin de journée vers 19h00 et un technicien est intervenu dessus :

Date 2008-05-07 19:37:24, Antoine made Server check: verrification du serveur en temperature ok (ajout de patte thermique pour le cpu), boot sur DD ok, ping ok services ouverts

A titre informatif, le temps de resolution de l'incident a ete de: 19m 37s

L'ajout de pate thermique n'y a apparemment rien fait... Le lendemain, c'est à dire jeudi 8 mai à 16h30, c'est l'apogée :

# hddtemp /dev/sda
/dev/sda: HDT722525DLA380                         : 65°C

# sensors | grep Temp 
Sys Temp:    +57.0°C  (high = +32.0°C, hyst = +16.0°C)  ALARM
CPU Temp:    +52.5°C  (high = +110.0°C, hyst = +75.0°C)

De plus sur les graphes de température, on remarque un delta entre la température mini et maxi quotidienne vraiment important : 20°C de delta pour la journée du jeudi 8 !

Pour retracer l'historique des échanges, voici le topic original : Surchauffe à Roubaix ?. Je n'ai malheureusement pas le droit de faire part de ce qui est passé sur la ML sd-basic, celle-ci n'étant pas publique.
Je peux comprendre que des soucis de refroidissement arrivent, mais qu'OVH trouve "normal" qu'un disque dur soit à plus de 55°C, il y a un gap ! Ah oui, ils ne refroidissent pas le capteur, j'avais oublié...

Update du 11 mai 2008 :

Les températures ont l'air de revenir un peu plus à la normale :

Update du 15 aout 2008 :

3 plantages aux alentours de 12h... Alors là c'est le fin du fin, le cpu a atteint les 110°C selon les graphes ! Aucune explication d'ovh sur le problème...

Kernel 2.6.25 & backport lm-sensors pour dedibox v2 et XL

hacky — Wed, 30 Apr 2008 22:16:00 +0200

Tiens, un kernel par hacky... Il n'avait pas dit qu'il ne compilait plus de kernel pour dedibox ?
Bon, j'avoue, je n'ai pas pu résister... Mais il a quelques petits trucs sympas en plus par rapport au kernel dedibox officiel :)
J'en ai aussi profité pour vous faire un magnifique backport de lm-sensors pour etch afin que vous puissiez voir les températures sur les dedibox v2.
Tout le détail est dans la suite.

Bon, désolé pour le bruit, mais on finit par une petite private joke pour Patrice : infogérance serveur linux

Tout d'abord, ce sont des kernels 32 bits ! A ne pas essayer sur du 64 bits
Voici donc un noyau 2.6.25 tout fraichement testé sur XL et v2. Par rapport au kernel officiel dedibox (le r8-1-smp-x32), les modifications sont :

Ajout du support watchdog sur les XL (module iTCO_wdt). Le watchdog sur les v2 était déjà inclus (module w83627hf_wdt)
Ajout du module coretemp afin de sonder les températures des core du T7200 de la XL

Ce kernel 2.6.25 est dispo ici : http://files.si7v.fr/kernel/2.6.25/

Côté lm-sensors, je vous ai fait des jolis backports etch en 32 et 64 bits. En effet le lm-sensors fourni par Debian etch est complètement perdu sur une carte mère de dedibox v2 et ne parvient pas à trouver les températures.
Ces paquets sont disponibles ici : http://files.si7v.fr/lm-sensors/

Nouveautés dedibox & comparatif serveurs dédiés

hacky — Wed, 09 Apr 2008 09:05:00 +0200

Suite à la sortie des nouveaux serveurs chez Dedibox, un petit décorticage de l'offre s'impose. Je vous propose en parallèle un bref comparatif entre les différentes offres de serveurs dédiés proposés actuellement chez OVH, Gandi et Dedibox.

De nouveau, Dedibox frappe un grand coup dans le monde des serveurs dédiés en proposant deux nouvelles gammes de serveurs à des prix très agressifs.
La dedibox V1 (Via C7 2GHz) est remplacée par la V2 qui possède une carte mère Intel basée sur un chipset SiS 662 et un CPU Intel Celeron 220, le tout épaulé par un disque de 160Go sata et 1Go de RAM.
La dedibox XL est une nouvelle venue, elle est clairement destinée au marché du dédié milieu/haut de gamme : carte mère basée sur chipset ICH7, CPU Intel Core2Duo T7200, 3Go de RAM, et un disque 500Go sata Hitachi à enregistrement perpendiculaire. En fouillant dans le dmidecode de ce serveur, on découvre que la carte mère est fabriquée par Kontron, fabricant de matériel embarqué pour l'univers médical, militaire etc... Cette carte mère est donc d'excellente qualité et les pannes matérielles risquent d'être assez rares.

Pour avoir une vue d'ensemble de ce qui se fait actuellement sur le marché de la location de serveur dédié ou virtualisé, rien de tel qu'un petit jeu de benchs, des jolis tableaux et graphiques pour faire un petit comparatif
Il est en pdf, et ça se passe ici : comparatif serveurs dédiés
Un autre jeu de tests a été réalisé par Patrice alias ptro, infogérant dedibox comme moi même (infogérance dedibox), les résultats sont condensés dans ce comparatif.

Kernel dedibox 2.6.24.2

hacky — Mon, 11 Feb 2008 23:31:00 +0100

Suite à la faille de sécurité vmsplice qui a fait pas mal de bruit sur le net depuis samedi dernier (CVE-2008-0010 et CVE-2008-0600). Il est indispensable de mettre à jour votre kernel si vous êtes dans la tranche 2.6.17 à 2.6.24.1. Alors, certainement pour l'une des dernières fois, voici le lien de téléchargement de la version 2.6.24.2 : http://files.si7v.fr/kernel/2.6.24.2/

Et là on va me demander : "pourquoi la dernière fois ?", et bien tout simplement vu que dedibox propose depuis peu l'IPv6, et que leurs derniers kernels intègrent le support IPv6, il n'y a pas de raison que je continue la branche "kernel dedibox + IPv6".

J’assume donc pleinement la responsabilité de cet échec et j’en tire les conséquences en me retirant du monde de la compilation de kernel dedibox

WiiGuitar sur Frets on Fire

hacky — Sat, 08 Dec 2007 19:28:00 +0100

Ou comment faire fonctionner sa WiiGuitar sous Linux sur le jeu Frets on Fire !

Je me suis fait un petit plaisir pour Noël : l'achat du jeu Guitar Hero 3 sur Wii accompagné de la guitare qui va bien.

Rien à dire, c'est un excellent jeu, et avec la guitare c'est le pied intégral...

Etant un fan de l'équivalent libre de Guitar Hero, à savoir Frets on Fire, je me suis posé la question s'il n'était pas possible de faire fonctionner cette guitare sous Linux et plus précisément sur Frets on fire.

La réponse est OUI ! C'est possible ! Et plus simplement que je ne le pensais. Voici le topo :

Tout d'abord, il faut savoir que la wiimote fonctionne en bluetooth. Il faut donc avoir sur votre PC un adaptateur bluetooth intégré (le cas des laptops) ou une petite clé usb bluetooth. Le PC doit être équipé de Linux et si possible sous Debian lenny ou sid ou encore sous Ubuntu Gutsy car les paquets pour contrôler la wiimote sont déjà packagés. Sinon il faudra compiler la librairie et les outils par ses propres moyens.

La librairie permettant de contrôler la Wiimote se nomme cwiid. Elle offre tous les outils nécessaires afin d'interfacer la wiimote à son PC.

Commençons donc le tutorial

Tout d'abord, ajoutons une règle udev afin de pouvoir utiliser le device uinput en utilisateur :

# vim /etc/udev/rules.d/020_permissions.rules

Et ajoutez la ligne :

KERNEL=="uinput", MODE="0666"

Ensuite chargeons le module uinput :

# modprobe uinput

Installons les paquets nécessaires :

# aptitude install libcwiid1 lswm python-cwiid wminput bluez-utils

Munissez vous de votre wiimote et appuyez sur le bouton 1 et 2 simultanément pour la passer en mode association. Pas besoin de maintenir les boutons enfoncés. Avec la wiimote en train de clignoter, nous allons lancer une détection des périphériques bluetooth pour voir si notre wiimote est détectée. L'affichage devrait donner quelque chose de ce genre :

$ hcitool scan
Scanning ...
        00:19:1D:6A:49:0A       Nintendo RVL-CNT-01

Si la wiimote n'est pas détectée, pas besoin de continuer ce tutorial, vous avez un souci de bluetooth

Il faut ensuite créer un fichier de mappings pour wminput. Cet utilitaire va permettre d'associer la wiimote au PC et de mapper des touches de clavier.

# vim /etc/cwiid/wminput/wiiguitar

Et y coller les lignes suivantes :

# Profil wiiguitar
Classic.A = KEY_F1
Classic.B = KEY_F2
Classic.X = KEY_F3
Classic.Y = KEY_F4
Classic.ZL = KEY_F5
Classic.Down = KEY_ENTER
Classic.Up = KEY_ENTER
Classic.Dpad.X = ABS_X
Classic.Dpad.Y = ABS_Y
Classic.LStick.X = ABS_HAT0X
Classic.LStick.Y = ABS_HAT0Y
Classic.RStick.X = ABS_HAT1X
Classic.RStick.Y = ABS_HAT1Y
Classic.Minus = BTN_SELECT
Classic.Plus = BTN_START
Classic.Home = BTN_MODE
Classic.L = BTN_TL
Classic.R = BTN_TR
Classic.ZR = BTN_TR2

On y est presque ! Plus qu'à lancer wminput avec les bonnes options. Adaptez bien évidemment la ligne de commande avec l'adresse MAC de votre wiimote.

$ wminput -c /etc/cwiid/wminput/wiiguitar 00:19:1D:6A:49:0A

Appuyez vite sur le bouton 1 et 2 de votre wiimote comme wminput vous l'indique. Si vous voyez un "Ready." s'afficher, vous êtes prêts à rocker sur frets on fire ! Laissez impérativement le terminal ouvert. Démarrez ensuite frets on fire, et testez ! J'ai laissé les touches par défaut de frets on fire et fait le mapping en conséquence, ne changez donc pas les paramètres du jeu.

Frets on fire avec une vraie guitare et pas un clavier, c'est vraiment beaucoup mieux ! En moyenne j'augmente mes scores de 25% avec la guitare.

Sur ce, bon rock !

Linux 2.6.23.8 pour dedibox

hacky — Fri, 30 Nov 2007 13:52:00 +0100

Aie, le dernier post date de février... Bon j'ai des excuses, beaucoup de choses ont changé : déménagement, création d'entreprise bref plus vraiment de temps à consacrer à ce blog. Mais je me rattrape aujourd'hui !

N'ayant plus de dedibox depuis mars 2007, je n'ai pas recompilé de kernel spécifique depuis. Or là, j'ai une dedibox de test sous le coude, et j'en ai profité pour tester la branche 2.6.23 qui inaugure le support natif du processeur Via C7.

Et bien bonne nouvelle, le serveur en question subit mes stress tests depuis bientôt 8 jours sans aucun freeze ! Sur les anciennes branches de kernel la machine tombait au bout de quelques heures grand maximum.

Comme d'habitude, ce kernel inclut le support du watchdog, du padlock, du NXbit et de l'IPv6.

A tester d'urgence pour ceux qui ont des problèmes de freezes. Merci à eux de faire des remontées dans les commentaires de ce billet.

Les paquets debian et fichier de config kernel sont là : http://files.si7v.fr/kernel/2.6.23....

Préférences spamassassin & MySQL

hacky — Tue, 13 Feb 2007 17:36:00 +0100

Voici un petit howto concernant la gestion des préférences spamassassin par utilisateur en base MySQL.
Chaque utilisateur peut avoir accès à ses préférences via un plugin SquirrelMail.

Ayant de plus en plus d'utilisateurs mail sur mes machines, et certains ayant des besoins spécifiques au niveau du filtrage des spams, il semblait évident qu'il faille changer de stratégie pour spamassassin (un seul utilisateur, une seule base bayes, un seul fichier de préférences).
Je me suis donc attelé à la tâche afin de migrer tout ça en base MySQL, et comme je ne suis pas du genre radin, je vous en fais profiter
Le howto a été réalisé sur une Debian sid.

Je pars ici du principe que vous avez les choses suivantes déjà fonctionnelles :

Postfix
Spamassassin en configuration mono-utilisateur
MySQL
Squirrelmail

Tout d'abord, sauvegardons la base bayes de l'utilisateur qui analyse les mails, je pars du principe qu'il se nomme spamd :

# su - spamd
$ sa-learn --backup > /tmp/sa_backup.txt

Créez une base dans votre MySQL, ou réutilisez celle que vous aviez déjà pour stocker vos utilisateurs virtuels. Je suis personnellement dans le second cas ici, la base s'appelle maildb. Passons à la création des tables nécessaires :

$ wget http://blog.hacky.info/public/base_spam.sql
$ mysql -u root -p maildb < base_spam.sql
Enter password:

Vous pouvez réutiliser le même utilisateur MySQL que postfix utilise pour aller consulter ses tables de configuration, mais il est beaucoup plus sécurisé de créer un autre utilisateur n'ayant accès qu'aux tables awl, bayes_expire, bayes_global_vars, bayes_seen, bayes_token, bayes_vars et userpref.

$ mysql -u root -p
Enter password:
mysql> CREATE USER 'spamd'@'localhost' IDENTIFIED BY 'password("motdepasse")';
Query OK, 0 rows affected (0.00 sec)
mysql> GRANT ALL ON `maildb`.`awl` TO 'spamd'@'localhost' WITH GRANT OPTION ;
Query OK, 0 rows affected (0.00 sec)
mysql> GRANT ALL ON `maildb`.`bayes_expire` TO 'spamd'@'localhost' WITH GRANT OPTION ;
Query OK, 0 rows affected (0.00 sec)
mysql> GRANT ALL ON `maildb`.`bayes_global_vars` TO 'spamd'@'localhost' WITH GRANT OPTION ;
Query OK, 0 rows affected (0.00 sec)
mysql> GRANT ALL ON `maildb`.`bayes_seen` TO 'spamd'@'localhost' WITH GRANT OPTION ;
Query OK, 0 rows affected (0.00 sec)
mysql> GRANT ALL ON `maildb`.`bayes_token` TO 'spamd'@'localhost' WITH GRANT OPTION ;
Query OK, 0 rows affected (0.00 sec)
mysql> GRANT ALL ON `maildb`.`bayes_vars` TO 'spamd'@'localhost' WITH GRANT OPTION ;
Query OK, 0 rows affected (0.00 sec)
mysql> GRANT ALL ON `maildb`.`userpref` TO 'spamd'@'localhost' WITH GRANT OPTION ;
Query OK, 0 rows affected (0.00 sec)

Éditons maintenant la configuration de spamassassin :
Changez la ligne OPTIONS du fichier /etc/default/spamassassin :

OPTIONS="--max-children 5 --username spamd --nouser-config --sql-config"

Commentez tout ce qui fait référence à vos anciens paramètres de configuration dans le fichier /etc/spamassassin/local.cf puis ajoutez ceci :

bayes_store_module              Mail::SpamAssassin::BayesStore::MySQL
auto_whitelist_factory          Mail::SpamAssassin::SQLBasedAddrList
user_awl_sql_table              awl
bayes_sql_override_username     root
user_scores_dsn                 DBI:mysql:maildb:localhost
user_scores_sql_username        spamd
user_scores_sql_password        motdepasse
user_awl_dsn                    DBI:mysql:maildb:localhost
user_awl_sql_username           spamd
user_awl_sql_password           motdepasse
bayes_sql_dsn                   DBI:mysql:maildb:localhost
bayes_sql_username              spamd
bayes_sql_password              motdepasse

Un petit redémarrage de spamassassin pour prendre en compte la nouvelle configuration :

# /etc/init.d/spamassassin restart

Et restaurons la sauvegarde de la base bayes :

$ sa-learn -u root --restore /tmp/sa_backup.txt

Pendant ce temps, on peut réinsérer en base les paramètres globaux qui étaient présents dans le fichier local.cf (les directives qu'on a commentées juste au dessus).

$ mysql -u spamd -p maildb
Enter password:
mysql> insert into userpref values ('@GLOBAL','required_hits','5.0','');
Query OK, 1 row affected, 1 warning (0.01 sec)
mysql> insert into userpref values ('@GLOBAL','rewrite_header Subject','*****SPAM*****','');
Query OK, 1 row affected, 1 warning (0.00 sec)
mysql> insert into userpref values ('@GLOBAL','report_safe','1','');
Query OK, 1 row affected, 1 warning (0.00 sec)
mysql> insert into userpref values ('@GLOBAL','report_contact','postmaster@hacky.info','');
Query OK, 1 row affected, 1 warning (0.00 sec)

Voila, c'est tout coté spamassassin !

Côté postfix, il faut créer un pipe aboutissant sur un script de filtrage. Ce script, nommé /usr/bin/antispam comporte ces lignes :

/usr/bin/spamc -u "$4" | /usr/lib/sendmail -i "$@"
exit $?

Pour l'appeler au moment de l'arrivée d'un mail, il faut modifier la configuration postfix dans le fichier /etc/postfix/master.cf :

Ajouter l'appel du pipe en modifiant la ligne smtp existante :

smtp      inet  n       -       n       -       -       smtpd
        -o content_filter=antispam

Et créer ou modifier le pipe antispam :

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

Il ne vous reste plus qu'à utiliser un plugin squirrelmail ou un autre panel afin d'autoriser vos utilisateurs à modifier leurs préférences : http://sourceforge.net/projects/php...

Il existe de nombreux panels d'administration pour cette base, le wiki de SpamAssassin en recense quelques uns : http://wiki.apache.org/spamassassin...

Linux 2.6.20 et NXbit dedibox

hacky — Wed, 07 Feb 2007 13:00:00 +0100

Après quelques heures d'acharnement sur une dedibox de test prêtée gentiment par Michael de l'équipe d'admins, un 2.6.20 a booté \o/

A première vue, il y a un souci avec le support NXbit du CPU C7 et ce noyau. Pour le faire amorcer convenablement, on a le choix soit de désactiver le NXbit du bios, soit de supprimer le support 64Gb highmem de la configuration kernel.

Le kernel 2.6.20-hacky n'utilise donc pas le NXbit , en attendant mieux... Le 2.6.20 apporte un bon nombre de modifications pour le driver sata_via, qui causait pas mal de soucis de plantages lors d'une charge I/O importante sur les kernels précédents (depuis le r6 dedibox).

Sources et image sont disponibles ici :http://files.hacky.info/kernel/2.6....
N'hésitez pas à faire des remontées si le souci d'I/O se reproduit toujours ou a disparu.

Changement de travail

hacky — Mon, 05 Feb 2007 18:40:00 +0100

Voila, c'est maintenant chose faite, je change de travail.

Un peu lassé par les tâches que je faisais à mon ancien boulot, et surtout une grosse envie d'évoluer au niveau des domaines abordés et des responsabilités, je pars chez Capensis.

Je deviens donc Architecte systèmes et réseaux à partir du 19 février 2007 !

Wiiiiiiiii !

hacky — Tue, 19 Dec 2006 13:42:00 +0000

La Wii est arrivée depuis samedi, et c'est une véritable drogue

Prise en main rapide, plaisir de jeu inégalé, bref un bon achat ! Dommage que les nunchuk soient en rupture de stock...

Pour ceux qui ont la chance de l'avoir aussi, voici mon code ami Wii : 0424 3070 8053 9994

OpenSSL 0.9.8c-4 et kernel 2.6.19 en test

hacky — Sat, 02 Dec 2006 21:05:00 +0000

Un petit billet rapide pour vous informer de l'apparition des paquets Debian d'OpenSSL en version 0.9.8c-4 patchés padlock :
http://files.hacky.info/openssl/0.9...

J'ai aussi recompilé le kernel linux 2.6.19 (config dedibox avec ajout IPv6) :
http://files.hacky.info/kernel/2.6....

Celui ci apporte un lot important de modifications (iptables, sata ...), mais les deux modifications intéressantes pour un serveur dedibox sont l'inclusion du driver du watchdog ainsi que le support padlock complet.
A la poubelle les anciens patchs

SMTP auth TLS : postfix avec SASL linké à IMAP

hacky — Fri, 10 Nov 2006 15:57:40 +0000

Une petite mise à jour du précédent howto. Cette fois ci, plus besoin de courier-authdaemon, la méthode rimap de saslauthd permet de se connecter à n'importe quel serveur IMAP pour l'authentification.

La distribution utilisée pour ce howto est une Debian avec les paquets sid suivants :

libsasl2, libsasl2-2, libsasl2-modules, sasl2-bin en version 2.1.22.dfsg1-1
postfix, postfix-mysql en version 2.3.4-1

Le paquet postfix-tls est maintenant obsolète (deprecated).

Je pars du principe que vous avez un postfix et un serveur IMAP de votre choix fonctionnels tous les deux.
Cette fois ci, la chaine utilisée se décompose de cette façon :

client >> postfix >> saslauthd >> serveur IMAP (local ou distant)

Installons les paquets suivants :

# aptitude install libsasl2 libsasl2-modules sasl2-bin openssl

Générons le certificat SSL valable 1 an pour le TLS de postfix :

# cd /etc/postfix # openssl req -new -outform PEM -out /etc/postfix/smtpd.cert -newkey rsa:2048 -nodes -keyout /etc/postfix/smtpd.key -keyform PEM -days 365 -x509

Répondez aux quelques questions demandées, la plus importante étant : "Common Name (eg, YOUR name) :", où il faudra indiquer le FQDN de votre machine (machine.domaine.org).
Corrigeons maintenant les droits sur le fichier de la clé pour éviter qu'un utilisateur mal intentionné vienne la lire.

# chmod o= /etc/postfix/smtpd.key

Ajoutez l'utilisateur postfix au groupe sasl, ceci permettra à postfix d'aller dialoguer avec saslauthd grâce au socket unix /var/run/saslauthd/mux.

# adduser postfix sasl

Passons maintenant à la configuration de saslauthd :
Editez le fichier /etc/default/saslauthd et modifiez les lignes correspondantes :

START=yes MECHANISMS="rimap" MECH_OPTIONS="nomdhote-ou-ip-de-votre-serveur-imap" OPTIONS="-r -c -m /var/run/saslauthd"

Remarque pour ceux qui utilisent postfix en chroot : il suffit de créer préalablement le répertoire /var/spool/postfix/var/run/saslauthd et de changer en conséquence la ligne OPTIONS du fichier ci dessus.

Créez le fichier /etc/postfix/sasl/smtpd.conf contenant :

pwcheck_method: saslauthd mech_list: plain login

Et finissons avec la configuration de postfix :

Editons le fichier /etc/postfix/main.cf, et ajoutons :

smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination smtpd_sasl_auth_enable = yes broken_sasl_auth_clients = yes smtpd_use_tls = yes smtpd_tls_cert_file = /etc/postfix/smtpd.cert smtpd_tls_key_file = /etc/postfix/smtpd.key

Pour des raisons de compatibilité de postfix, il faut créer le lien symbolique suivant :

ln -s /etc/postfix/sasl/smtpd.conf \ /usr/lib/sasl2/smtpd.conf

Enfin, redémarrons le tout :

# /etc/init.d/postfix restart # /etc/init.d/saslauthd restart

Voila ! Il ne vous reste plus qu'à configurer votre client mail favori pour se connecter en TLS avec authentification "PLAIN", y indiquer votre login et votre mot de passe.

Kernel optimisé dedibox et OpenSSL 0.9.8c-3

hacky — Tue, 10 Oct 2006 23:23:12 +0000

Après pas mal de tests réalisés (merci Nicolas & Joachim), voici un kernel linux 2.6.18 sauce debian avec :

patch pour le watchdog des dedibox V1 : module w83697hf_wdt (à charger avec modprobe w83697hf_wdt wdt_io=0x4e)
patch pour le support du SHA1/SHA256 du padlock

Ce kernel dispose de la configuration du kernel dedibox_r5 avec l'ajout de l'IPv6 (pratique pour les tunnels v6 over v4).
Par ici la bonne soupe : http://files.hacky.info/kernel/

Et comme un kernel ne fait pas tout, j'ai repackagé OpenSSL avec pour y intégrer un padlock 100% fonctionnel (AES, SHA1, SHA224 et SHA256).

C'est par là : http://files.hacky.info/openssl/0.9.8c-3/

Merci aux auteurs des patchs :
Michal Ludvig <michal@logix.cz> pour la partie padlock kernel & OpenSSL.
Samuel Tardieu <sam@rfc1149.net> pour le patch watchdog.

OpenSSL 0.9.8c-2 Debian & padlock

hacky — Sat, 30 Sep 2006 12:38:00 +0000

Euh, hum... On va dire que je radote, mais vu la fréquence des mises à jour de sécu OpenSSL en ce moment j'ai une excuse !
Comme d'hab donc, nouveaux paquets Debian sid d'OpenSSL générés avec le patch pour inclure l'engine PadLock.
Votre dedibox vous dira merci

Paquets dispo ici : http://files.hacky.info/openssl/0.9...

OpenSSL 0.9.8c-1 Debian & padlock

hacky — Mon, 18 Sep 2006 20:55:27 +0000

Et hop, on recommence...
Mise à jour d'OpenSSL en sid aujourd'hui, donc j'ai repackagé la version Debian sid avec la modification pour inclure le padlock.

Les paquets binaires 386 et sources sont ici : http://files.hacky.info/openssl/0.9.8c-1/

Filer ready to rock !

hacky — Sun, 17 Sep 2006 10:43:00 +0000

Il est opérationnel depuis mercredi soir et a remplacé avantageusement mon ancienne Sun Ultra5.

Niveau matos :

Carte mère Gigabyte GA-K8NE
AMD Sempron 2800+ 64bits
512 Mo DDR PC3200
1 hdd IDE Exelstor de 80Go (système)
3 hdd sata2 Seagate 250Go (données)
alim Antec Neo HE 500W (alim à haut rendement pour moins pleurer quand on reçoit sa facture EDF)

C'est donc la nouvelle passerelle de l'appart', mais il a surtout une utilité de serveur de fichiers avec son raid5 de 3 disques Seagate sata2 250Go.

Je suis d'ailleurs agréablement surpris par les performances d'un raid5 soft en sata2 :
Timing buffered disk reads: 370 MB in 3.01 seconds = 123.12 MB/sec

Merci au magasin Micro-Clic situé 28 rue de Fruges à Anvin (62134) pour la fourniture de la majorité des pièces de cette machine, coup de pub mérité

OpenSSL 0.9.8b-3 Debian & padlock

hacky — Thu, 07 Sep 2006 23:38:46 +0000

En espérant que ça serve à quelqu'un d'autre qu'à moi...
J'ai patché le paquet OpenSSL de Debian unstable (sid) afin d'apporter le support du padlock, qui est désactivé par défaut.
Le padlock est une partie spécifique incluse dans les processeurs C3 et C7 de chez VIA et qui est dédiée à la gestion de la crypto. C'est super pratique pour faire des VPN chiffrés en AES-256 sans presque aucune charge CPU par exemple

Les paquets deb compilés et les sources sont disponibles ici : http://files.hacky.info/openssl/