Quelques digressions sous GPL...

Aller au contenu | Aller au menu | Aller à la recherche

vendredi, février 12 2010

Le vendredi, c'est script !

Mon vieux script de backup a rendu l'âme récemment. Le pauvre ne tenait plus. Aller comprendre. N'empeche que j'avais envie de refaire les choses bien, et de rajouter des contrôles et quelques fonctions.

J'ai donc ouvert mon vim pour gratter du bash, ça donne:

http://jve.linuxwall.info/ressources/code/bkp_sender.sh

En gros:

  1. backup mysql avec un fichier par database (au lieu d'un fichier pour tout)
  2. backup des fichiers avec gestion des exclude
  3. backup openldap dans fichier ldif
  4. transfert scp avec contrôle de signature SHA512+RSA avant et après le transfert

Et le tout sans aucune action de l'utilisateur. La seule chose à faire est de configurer les variables et de mettre en place une clé SSH pour envoyer les fichiers et lancer la commande de vérification de signature.

Sur un linux classique, la plupart des variables fonctionneront sans modification. Par contre il faudra obligatoirement éditer LISTFILETOARCHIVE (la liste des fichiers à archiver) et les variables SCP pour la connexion au serveur de destination.

mercredi, janvier 27 2010

Java pas marcher !

computer bug Rhodidiou ! Ca y est, je suis de mauvaise humeur... Alors que je commençais tout juste à me dire que Java ca pouvais être pas mal de temps en temps, voilà que je perd deux heures sur un problème à la con !

Je m'explique.

Aujourd'hui, mon serveur Alfresco arrive en production. Jolie petite machine sous Debian avec Tomcat dessus et tout et tout. Il démarre, le gars dans le datacenter m'annonce fébrilement qu'il a branché le cable, je test et hop je vois ma page s'ouvrir. La magie du moment m'émeut, alors empli de confiance je tente la page de login d'alfresco share. Et là, tout s'enchaine !

Java a la particularité de savoir vous insulter longuement et goulument dans un langage que vous ne comprendrez de toute façon jamais. Genre "j'ai pas pu ouvrir le fichier alors je te fait un dump complet des tes 4 GO de mémoires dans syslog". Sympa, mais pas pour le diagnostic. Alors tout bon sysadmin qui a déjà eu affaire à java sais qu'une trace de jvm c'est encore plus désagréable à contempler qu'un tableau de Joan Mitchell...

Celle qui m'agressait cette après-midi s'appelait, de son petit nom :

15:07:05,510 INFO  [org.alfresco.config.JndiPropertiesFactoryBean] Loading properties file from class path resource [alf
resco/repository.properties]                                                                                            
15:07:05,514 INFO  [org.alfresco.config.JndiPropertiesFactoryBean] Loading properties file from class path resource [alf
resco/domain/transaction.properties]                                                                                    
15:07:05,514 INFO  [org.alfresco.config.JndiPropertiesFactoryBean] Loading properties file from URL [file:/var/lib/tomca
t6/shared/classes/alfresco-global.properties]                                                                           
15:07:06,309 INFO  [org.alfresco.config.JndiPropertyPlaceholderConfigurer] Loading properties file from class path resou
rce [alfresco/alfresco-shared.properties]                                                                               
15:07:10,794 WARN  [org.hibernate.cfg.SettingsFactory] Could not obtain connection metadata                             
org.apache.commons.dbcp.SQLNestedException: Cannot create PoolableConnectionFactory (Communications link failure        
                                                                                                                        
The last packet sent successfully to the server was 0 milliseconds ago. The driver has not received any packets from the
 server.)                                                                                                               
        at org.apache.commons.dbcp.BasicDataSource.createDataSource(BasicDataSource.java:1225)                          
        at org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:880)                              
        at org.springframework.orm.hibernate3.LocalDataSourceConnectionProvider.getConnection(LocalDataSourceConnectionP
rovider.java:81)                                                                                                        
        at org.hibernate.cfg.SettingsFactory.buildSettings(SettingsFactory.java:84)                                     
        at org.hibernate.cfg.Configuration.buildSettings(Configuration.java:2073)                                       
        at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1298)                                 
        at org.springframework.orm.hibernate3.LocalSessionFactoryBean.newSessionFactory(LocalSessionFactoryBean.java:805
)                                                                                                                       
        at org.springframework.orm.hibernate3.LocalSessionFactoryBean.buildSessionFactory(LocalSessionFactoryBean.java:7
45)                                                                                                                     
        at org.springframework.orm.hibernate3.AbstractSessionFactoryBean.afterPropertiesSet(AbstractSessionFactoryBean.j
ava:134)                                                                                                                
        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowi
reCapableBeanFactory.java:1203)                                                                                         
        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireC
apableBeanFactory.java:1172)                                                                                            
        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapab
leBeanFactory.java:427)                                                                                                 
        at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:249)      
        at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegis
try.java:155)                                                                                                           
        at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:246)          
        at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:160)          
        at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveReference(BeanDefinitionValueRes
olver.java:267)                                                       

et ça continue pendant des kilomètres... Faut savoir que, là dedans, ya une seule info intéressante, c'est ça :

Caused by: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure                         

Bon... Donc Tomcat se ramasse en douze façon Nikolay Davydenko en quart de finale d'un tournoi du grand Chelem. Reste à savoir pourquoi. Mon serveur tomcat est bien lancé, netstat -taupen|grep mysql me le montre bien en LISTEN sur 127.0.0.1.. donc j'en fait quoi moi, de ma tartine ?

Reste les grands moyen, obligé d'installé un tcpdump sur un serveur de prod tout propre... m'enfin bon, c'est ça ou l'aller-retour sur l'A86. Alors je branche mon port en écoute façon

tcpdump -w trace_tomcat_mysql.pcap -s 16436 -Svni lo tcp and port 3306

Et voilà qu'il me retourne le truc suivant :

wireshark tomcat

Faut cliquer sur l'image, sinon vous allez vous faire mal aux yeux. Bref, ce qu'il me dit mon wireshark, c'est que le Tomcat il essai de se connecter au Mysql en IPv6... Pourquoi il fait ça ? J'en sais rien... Est-ce qu'il le faisait déjà avant et que c'est coté MySQL que quelque chose à changé ? J'en sais rien. Ce qui est sur, c'est que MySQL ne bind pas son port en IPv6. Donc ça peut pas marcher...

2 heures de galères....

Ouaip, deux heures, ca explique le coté un peu nerveux du billet. Entre les redémarrages de tomcat en changeant les paramètres, les tentatives de modification du port coté MySQL, j'ai même pensé à un problème de security policy de Debian... niveau noeud aux cerveaux, on fait pas mieux.

Alors je vous fait pas attendre plus longtemps, le problème c'est apparemment une mise à jour de cette $%*££ù* de JVM qui fait privilégie maintenant les requêtes en IPv6 sur IPv4. Me demandez pas quel est l'@&%ù** qui a décidé ça sans prévenir personne, mais dans le genre belle bêtise, elle est pas mal.

Bref, ça se corrige en rajoutant le paramètre suivant dans les JAVA_OPTS du fichier /etc/default/tomcat6:

-Djava.net.preferIPv4Stack=true

Redémarrage fébrile du Tomcat.

Le regard figé sur mon tail -f /var/log/tomcat6/alfresco.log

Pas de message bizarre, cela marcherait-il ?

YES ! La page de login !!!!

Voilà, c'était 3615 mylife dans la catégorie mésaventures de sysadmin.

mardi, décembre 8 2009

Du Chaos, mes amis, du Chaos !

Kitty evilL'inconvénient de vivre dans un appartement en plein Paris, c'est que l'espace manque rapidement. Moi, perso, tant que j'ai de la place pour brancher des machines à plus savoir quoi en faire, tout va bien, mais mademoiselle c'est une autre histoire. En fait, elle aimerait bien qu'on ai un chat à la maison. Vous savez ces trucs pleins de poils, au demeurant mignon et sympa mais, bon, je dois normalement pouvoir remplir ces fonctions. Sauf, peut être, pour le coté "laisse tes poils partout et surtout sous le lit". La dessus, je dois admettre que j'ai du mal.

Bref, je digresse.

Donc mademoiselle voudrait un chat, et elle a trouvé un parfait argument lorsque je lui ai parlé de mon projet d'acquérir une eKey. Selon ses dires, si l'objectif de l'objet est de générer du chaos, il serait tout autant efficace de disposer d'un de ces petits diables poilu et de le laisser toute la journée dans l'appartement.

Alors c'est quoi une eKey ? En fait, dans tout système Linux (et Unix souvent) existe un puit d'entropie nommé /dev/random. Le noyau collecte des bits un peu partout sur le système, dans les drivers des périphériques surtout, là ou l'activité est supposée difficile à deviner, et remplit le puit avec ces bits. Dés que l'on utilise un tant soit peu de crypto, OpenSSL, OpenSSH, etc..., on pioche dans ce puit. La problème est qu'il est pas bien grand notre puit, puisque sa taille se limite à 4KB. C'est d'ailleurs à cause de cette taille réduite que les systèmes disposent de deux périphériques: /dev/random et /dev/urandom. La différence entre les deux ? Ils fournissent les mêmes bits aléatoires collectés par le système mais, lorsque le puit est vide, /dev/random va bloquer jusqu'à ce qu'il se remplisse alors que /dev/urandom va bricoler pour renvoyer d'autres bits, moins aléatoires, mais sans bloquer le programme appelant.

Tout l'intérêt de l'eKey est donc de fournir une source externe d'entropie afin de s'assurer que ce puit n'est jamais vide, et que l'on peut donc utiliser /dev/random uniquement sans avoir à craindre de ralentir ses programmes. C'est particulièrement indispensables sur des serveurs réalisant un grand nombre de connexions SSL !

Revenons donc à notre Chaton Chaotique

Ma chère et tendre me propose donc d'utiliser l'incroyable capacité de ces petites bêtes à générer du chaos dans mon serveur (celui qui héberge ce site) plutôt que d'enrichir le britannique en important sa technologie. Elle n'a pourtant aucune famille du coté Napoléonien, mais je dois admette qu'elle marque un point.

Le pire, c'est que techniquement, c'est jouable. Une vieille webcam recyclée en caméra de surveillance du salon, un chaton qui passe sa journée à sauter du canapé à la table de cuisine, à fourrer ses pattes sur mes vinyles et à bouffer mes RJ45 ! En backend, un petit programme pour convertir les données reçues en bits à injecter dans /dev/random. Et en plus ça pourrait être rigolo à faire !

Bref, me voilà coincé. Mon argument principal de refus se retrouve confronté à la curiosité technique... Que faire ? Trouver une parade technologique sur laquelle ronger mon frein en attendant que l'espace vital du doux foyer conjugal soit compatible avec ledit prédateur de pelotes de laines.

cat /proc/sys/kernel/random/entropy_avail

Alors que je lisait un billet des plus intéressant sur planet.debian.org, j'ai réalisé que le niveau d'entropie disponible sous Linux était exporté dans /proc. C'est fou la quantité de choses que l'on trouve dans ce pseudo système de fichiers ! Curieux de voir si mon modeste système, qui n'est en fin de compte utilisé que pour des sites persos et des services à quelques personnes du domaines linuxwall.info, nécessitait réellement une source externe d'entropie, je me suis donc fendu d'un minuscule script bash et de quelques lignes de gnuplot.

Ca donne ça :

#! /bin/sh
while [ 1 ]
do
   DATE=`date +%s`
   ENTLVL=`cat /proc/sys/kernel/random/entropy_avail`
   echo "$DATE:$ENTLVL" >> entlvl.log
   sleep 1
done

Qui remplit gentillement un fichier entlvl.log avec des lignes du type :

julien@zerhuel:/$ tail entlvl.log
1260265664:177
1260265665:183
1260265666:191
1260265668:265
1260265669:265
1260265670:305
1260265672:322
1260265673:175
1260265675:199
1260265676:220

(le premier champ, c'est du temps Unix, le deuxième, c'est des octets).

Et que l'on va ensuite utiliser pour génerer des graphiques gnuplot avec le script suivant :

set title "Entropy level on zerhuel.linuxwal.info"
set xlabel "time"
set ylabel "bits"
set yrange [0:4200]

set terminal png
set output "/data/www/pki/entropy_level.png"

set xdata time
set timefmt "%s"
set format x "%d/%m/%y:%Hh%M"
set xtics nomirror rotate
set datafile separator ":"
plot '/data/julien/code/scripts/entropylevel/entlvl.log' using 1:2 with dots

Verdict ?

Tout cela a tourné sur ma machine pendant deux mois, en marquant une valeur toutes les secondes. La courbe en date de ce matin donne :

entropy level

Plus précisement, si on regarde une période de deux heures pendant laquelle je travaillais intensément sur la machine (HTTPS + 2*SSH), ca donne ça :

entropy level 2h

Ces deux graphs montrent bien qu'on est loin du niveau de famine nécessitant une source externe d'entropie. Ca se confirme à l'usage, je n'ai jamais ressenti de lenteur dans l'établissement de connexios (sauf quand je joue avec --limit et iptables, mais c'est autre chose :p ).

On peut également calculer les moyennes pour vérifier le niveau d'entropie. Si ça vous amuse de jouer en bash, ça se fait facilement de la façon suivante:

Changez juste le nom du fichier 'entlvl.log' deux fois dans la ligne suivante:

julien@zerhuel:/$ sum=0;for i in `cat entlvl.log |cut -d : -f2`;do sum=$(($sum+$i));done;echo $sum / `wc -l entlvl.log|awk {'print $1'}`|bc -l

Sur deux mois, j'ai 3106.80. Donc plutôt un puit d'entropie bien remplit.

En période de boulot (sur deux heures), j'ai 2336.70. Donc c'est plutôt bien plein également.

En gros, et pour finir

Ca veut dire deux choses, ces petites mesures (outre le fait que j'ai encore passé du temps à geeker sur un truc qui potentiellement ne sert à rien).

  1. Sur votre serveur perso, même avec une utilisation intensive, la collecte d'entropie mise en place par le noyau est suffisante. Maintenant ca peut varier selon la machine. Un collègue me parlait des mini-pc à base de mémoire flash sur lesquels l'ouverture de session SSH peut prendre assez de temps pour se repasser l'intégrale d'Annie Cordy.
  2. Sweetie, I'm afraid the chaotic kitty will not be needed anytime soon... :p

Ouf !

vendredi, août 21 2009

Droper les réseaux indésirables avec Netfilter et SpamHaus

Un peu de bidouille netfilterienne pour bloquer les réseaux définit par spamhaus comme indésirables. On pourrait faire cela avec ipset, puisque l'outil est désigné pour, mais apparemment, il faut jouer un peu avec le noyau et recompiler iptables pour avoir une version qui marche sur Lenny.

Du coup, j'ai trouvé que ca aller plus vite de le faire directement dans netfilter, avec quelques lignes de bash.

L'idée est simple: on prend toutes les NOUVELLES connections entrantes et on les fait passer une fois par une chaine spéciale qui va vérifier que l'IP source n'est pas listée par spamhaus. Donc il nous faut cette chaine spéciale et un petit script qui va, tous les matins, récupérer la nouvelle liste de spamhaus et l'intégrer dans netfilter.

C'est parti.

Dans un premier temps, on va créer deux chaines : une CHECKDROPLIST qui va contenir les réseaux et une LOGCHECKDROPLIST qui va loguer avant de DROPer les paquets.

iptables -N CHECKDROPLIST

iptables -N LOGCHECKDROPLIST

iptables -A LOGCHECKDROPLIST -j LOG --log-prefix \

"SOURCE IN DROPLIST" --log-level debug

iptables -A LOGCHECKDROPLIST -j DROP

Pour le moment, on a rien mis dans CHECKDROPLIST, ca va venir après.

Maintenant, il faut que l'on filtre les paquets entrant. Mais ou ? En fait, cela dépend de l'utilisation que vous faites de la machine. Dans mon cas, je n'effectue pas de routage, et donc la chaine FORWARD n'est pas utilisée. Je vais donc pouvoir filtrer simplement dans la table "filter" de la chaine "INPUT".

Pour un récapitulatif des tables et chaines, voir ici : http://wiki.linuxwall.info/doku.php?id=ressources:dossiers:advanced_networking:1_netfilter_en_grand

Dans ma chaine INPUT, j'ai tout d'abord une règle pour accepter les connections ESTABLISHED, et juste après je vais ajouter ma règle de check de la droplist. Encore après, je peux positionner toutes mes règles de filtrage classiques.

La règle de filtrage ne va s'appliquer que sur les états NEW, pour pas alourdir le filtrage et impacter les perfs :

iptables -t filter -A INPUT -i eth0 ! -s 192.168.1.0/24 \
-m state --state NEW -j CHECKDROPLIST

OK, on est pret ! La configuration actuelle ne va pas perturber le fonctionnement normal du firewall, les nouvelles connections vont juste passer dans CHECKDROPLIST et comme rien n'y est fait pour le moment, vont continuer leurs chemin.

Maintenant, le script que l'on va mettre en place va récupérer le fichier sur spamhaus.org, le parser et injecter les adresses dans la chaine CHECKDROPLIST. On va faire passer ces adresses dans une regex pour éviter d'injecter n'importe quoi.



#! /bin/sh

# get the drop list from spamhaus

# and import it into netfilter

URL=http://www.spamhaus.org/drop/drop.lasso;

DEST=/root/droplist/drop.lasso.`date +%s`



wget $URL -O $DEST



IPT=/sbin/iptables



if [ -e $DEST ]

then

  # drop existing set of rules

  $IPT -F CHECKDROPLIST

  # add new rules

  for i in `cat $DEST | awk {'print $1'}|\

           grep -E "^[0-9]{1,3}\.[0-9]{1,3}\.[0-9]\

           {1,3}\.[0-9]{1,3}\/[0-9]{1,2}$"`

  do

      $IPT -A CHECKDROPLIST -s $i -j LOGCHECKDROPLIST

  done

fi

La regex pourrait être améliorée mais j'ai pas trop eu le temps de la paufiner (avis aux amateurs).

Je vous laisser tester ça chez vous. Au jour d'aujourd'hui, ça m'importe 158 réseaux dans la chaine CHECKDROPLIST. Je vais laisser tourner ça quelques jours puis je m'attarderais sur les stats pour voir si ya vraiment un intérêt à bloquer ces réseaux.

.

jeudi, août 6 2009

Roundcube, simple mais super efficace !

roundcubeCa fait maintenant quelques temps que le webmail de linuxwall est roundcube. J'aime bien cet outil car il est réellement épuré et ne reprend que les fonctions vraiment importante du mail. Ici, pas de calendrier, de gestion partagées des taches, de notifications dans tous les sens comme on en trouve dans quasiment tous les webmails du moment, dans leurs folles courses vers le collaboratif. Roundcube fait simplement son travail: envoyer et recevoir des emails, proprement, et gérer tout cela dans des dossiers IMAP.

Jusque récemment, certaines features me manquait tout de même cruellement. Et comme la sortie imminente de la 0.3 corrige certains de ces manquements, je me suis dit qu'il fallait bien que j'en parle :) (et puis, c'est l'été, tout calme au bureau, tout ça machin).

La demo

Parce que, les discours c'est bien mais le test c'est mieux, Roland Liebl à mis en ligne une demo de la version de dev de roundcube. Ca se trouve ici : http://mail4us.net/dev (avec le compte demo/demo). Bon, alors là, Roland il a chargé tout plein de pleuguines, alors forcément ça fait un peu le café et le couscous. Mais dans sa version de base, roundcube est vraiment épuré.

Les Plugins

voir la liste, et pour les codeurs, c'est par là

C'est LA grosse évolution de la version 0.3. Une API de plugin permet maintenant de développer des composants sans toucher au core. C'est comme cela qu'en quelques semaines, le nombre de contributions a été multiplié par.... pfiou.... beaucoup ! (jetez un coup d'oeil sur la mailing list et vous verrez)

Parmi les plugins les plus intéressants, on a un module GnuPG en cours de développements, et un module managesieve pour *enfin* intégrer la gestion des filtres.

Managesieve

Parce que les gens de roundcube font les choses proprement, ils ont toujours refusé d'intégrer du filtering de mail coté client. Le filtrage en php, ca prend des ressources, et ca n'est actif que quand l'interface est ouverte. Au lieu de cela, un protocole répondant exactement à ce besoin existe dans la grande majorité des serveurs mails (dovecot, cyrus-imap, ...), c'est Sieve.

Sieve, dont j'avais déjà parlé là-bas, est utilisable en ligne de commande via une sorte de shell qui permet d'entrer les règles de filtrage.

filtre roundcube

Mais, évidemment, c'est pas pratique pour des utilisateurs n'ayant pas accès au shell. Une interface pour sieve dans roundcube était donc indispensable, et c'est maintenant chose faite. Même si c'est assez limité en options de filtrage pour le moment.

Certificate Authentication

Ouais ! T'as bien lu ! l'authentification par certificat client. Bon, j'ai pas encore regardé ce qu'il y avait là-dedans, mais j'imagine qu'Apache (ou tout autre webserver) fait suivre les infos du certificat client envoyé lors du SSL Handshake à Roundcube, et ce plugin parse les champs X509 pour en sortie les infos d'authentification.

Bref, de la pure authentification forte comme on en met dans les banques et chez les impots. Faut absolument que je test ça !

Et pleins d'autres

La liste complète, et en constante évolution, est là. Pour le moment c'est un peu le far west, tout le monde code dans tous les sens. J'imagine qu'avec le temps, quelques gros plugins vont sortir du lot (j'ai d'ailleurs beaucoup d'espoir dans le plugin d'encryption).

Et les Core Features

J'en ai profité pour tester le STARTLS sur IMAP et SMTP. C'est une feature de la 0.2 mais comme je n'avais alors pas testé... Pour imap, c'est super simple, il suffit de suivre les commentaires du code. Pour smtp, j'ai un peu plus galéré (au point d'en faire un thread chez les devs) surtout parce qu'il existe deux supports différents pour SSL et TLS dans SMTP. SSL signifie création d'un canal chiffré au début de la communication entre le client et le serveur. TLS signifie réponse a la capability STARTTLS annoncée par le serveur, on a donc un début de communication en clair, puis un passage en mode starttls. C'est de dernier mode que je voulais, et pour l'activer, il faut configurer le fichier main.inc.php de la façon suivante :

// use this host for sending mails.                                       
// to use SSL connection, set ssl://smtp.host.com                         
// if left blank, the PHP mail() function is used                         
$rcmail_config['smtp_server'] = 'localhost';                        

// SMTP port (default is 25; 465 for SSL)                                 
$rcmail_config['smtp_port'] = 25;                                         

// SMTP username (if required) if you use %u as the username RoundCube    
// will use the current username for login                                
$rcmail_config['smtp_user'] = '%u';                                       

// SMTP password (if required) if you use %p as the password RoundCube    
// will use the current user's password for login                         
$rcmail_config['smtp_pass'] = '%p';  

// SMTP AUTH type (DIGEST-MD5, CRAM-MD5, LOGIN, PLAIN or empty to use     
// best server supported one)                                             
$rcmail_config['smtp_auth_type'] = ''; 

En supposant que le serveur SMTP (ici, postfix) soit configuré correctement :

# TLS server options                                                      
smtpd_use_tls = yes                                                       
smtpd_tls_auth_only = yes                                                 
smtpd_tls_security_level = may                                            
smtpd_tls_key_file = [keyfile]
smtpd_tls_cert_file = [pemcert]
smtpd_tls_CAfile = [cafile]
smtpd_tls_loglevel = 2                                                    
smtpd_tls_received_header = yes                                           
smtpd_tls_session_cache_timeout = 3600s                                   
tls_random_source = dev:/dev/urandom                                      
smtpd_tls_ask_ccert = yes                                                 
smtpd_tls_req_ccert = no    

Le code de roundcube va appeler le mode STARTTLS lorsque l'authentification est demandée (les variables 'smtp_user' et 'smtp_pass' sont renseignées). Si la configuration ne correspond pas exactement à cela (coté roundcube, et modulo l'adresse du serveur), alors le mode STARTTLS échoue. C'est un poil touchy mais assez logique au final.

De fait, lors de l'envoi d'un mail, on retrouve dans les headers les infos suivantes :

Received: from pki.linuxwall.info (localhost [127.0.0.1])
    (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
    (Client did not present a certificate)
    (Authenticated sender: julien@linuxwall.info)
    by zerhuel.linuxwall.info (Postfix) with ESMTPSA id A5FAAEBC1B;
    Thu, 6 Aug 2009 13:28:51 +0200 (CEST)

Comment ça "Client did not present a certificate" ?? Ha mais il va falloir corriger cela très vite ! J'espère, d'ailleurs, que cela fera parti du fameux plugin Encryption.

Et les threads ???

Haaa... les threads. Ca c'est, après le filtrage des mails, la feature qui me manque le plus. Mais, patience, car ça arrive ! En fait, c'est déjà développé et n'attend plus que la release de la 0.4 pour passer en stable.

Pour plus de lecture sur le sujet, voir ici : http://lists.roundcube.net/mail-archive/dev/2009-07/0000131.html

Voilà, j'espère que ça vous aura mis l'eau à la bouche. Roundcube, c'est bon, mangez-en !

- page 1 de 2