Une solution est trouvable ici : http://camaya.net/gloox/list/dev/msg01950.html. Afin de ne pas perdre le message je le poste ici :

Hi,

Found a small bug in configure.ac that caused SRV record lookup to be
disabled on my Debian system. Please see patch below.

// Erik

Index: branches/1.0/configure.ac
===================================================================
--- branches/1.0/configure.ac (revision 4368)
+++ branches/1.0/configure.ac (working copy)
@@ -253,7 +253,7 @@
AC_MSG_CHECKING([for res_query in -lresolv (alternate version)])
save_libs="$LIBS"
LIBS="-lresolv $LIBS"
- AC_LINK_IFELSE([AC_LANG_PROGRAM([[#include <resolv.h>]],
[[res_query(0,0)]])],
+ AC_LINK_IFELSE([AC_LANG_PROGRAM([[#include <resolv.h>]],
[[res_query(0,0,0,0,0)]])],
[AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_RES_QUERY)
have_res_query=yes],

--
Erik Johansson
Home Page: http://ejohansson.se/
PGP Key: http://ejohansson.se/erik.asc


Il suffit donc de compiler le paquet. Les étapes pour recompiler un paquet Ubuntu sont ici : http://www.moosechips.com/2008/09/ubuntu-rebuild-a-source-package/).

Une fois le configure.ac modifié, lancer aclocal, puis autoreconf. Et enfin la compilation du paquet. Il sera peut-être nécessaire d'installer libtool.

Une fois installé, gloox supporte les records SRV .

Il y a quelques temps - peut-être 2 ou 3 mois - il y avait eu des problèmes de connexion vers d'autres serveurs Jabber (notamment le serveur de gmail, c'était tout de même gênant avec le nombre d'utilisateurs gtalk) à cause d'un câble défectueux chez leur hébergeur, câble qui n'a apparemment pas été changé. Après quelques temps, les routes avaient été changées, et le trafic ne passant plus par le câble défectueux, plus aucun problèmes .

Depuis environ une semaine, le serveur est down à cause d'un problème hardware, mais n'a toujours pas été rebooté. Peu importe les raisons, j'ai décidé de monter mon propre serveur afin de ne plus subir ce genre d'inconvénients. Au moins, s'il y a un problème, je pourrai m'occuper de le régler moi même !

Un apt-get et une génération de certificat chez cacert plus tard, j'ai un serveur ejabberd qui tourne. Aucun soucis, au maximum 30mins avec les 1ers tests, tout est nickel.

J'ai configuré mon deuxième domaine - avec son propre certificat, merci TLS, aux chiottes SSL, j'attends que la propagation DNS se fasse pour tester, mais ça devrait rouler.

Je tiens à remercier l'APINC pour le super service qu'ils m'ont fourni pendant plus de 5 ans gracieusement ! Ca m'a décidé à m'y mettre, c'est vraiment pas sorcier .

Jabber, c'est bon, mangez-en.

Mais bon, il a finit par rendre l'âme, le disque dur ne voulant plus rien savoir. Je l'ai donc laissé au fond d'un tiroir. Mais j'ai vu récemment sur le net qu'on pouvait changer le disque des iPod par une carte compact flash... je l'ai donc ressorti pour tester ça.

J'ai acheté un adaptateur CF 1.8" IDE sur eBay, et j'ai branché tout ça dans l'iPod. Là, il m'affiche le message comme quoi le disque n'est pas reconnu. Normal. Donc, je le branche sur mon laptop windows... je restaure l'iPod avec iTunes... pareil ! De plus, il est sensé m'afficher l'icône selon laquelle il faut brancher l'iPod au secteur... ce qu'il ne fait pas.

Bref... j'ai un autre iPod dans un autre tiroir, celui de mon frère, qui a rendu l'âme pour les mêmes raisons. Hop, je branche... pareil. Je me dis que j'ai dû me louper avec l'adaptateur, il doit être grillé... donc j'en commande un deuxième, ça en fera un pour le 2ème iPod au pire .

Mais, idem. J'avais déjà testé avec 2 CF différentes. J'en teste une 3ème, j'ai canibalisé celle qui est branchée dans mon PCHC. Et là, miracle, ça fonctionne ! Apparemment, il faut une carte qui supporte le "DMA" si on en croit la description du produit sur le site. Ce n'était pas très clair... enfin bon du moment que ça marche, ça me va .

J'ai maintenant un iPod de 4G avec une carte de 4Go .

Bref, il faut que je change de carte. Je pars donc me procurer une 8800GTX, le meilleur rapport qualité prix à mon goût aujourd'hui. Mais il n'y en a pas au magasin où je me suis rendu. Par contre, il y a une 9800GX2, la carte la plus puissante actuellement sur le marché. Elle intègre 2 GPU, et permet donc de faire du SLI (appelé MultiGPU quand c'est sur la même carte). Je me dis, pourquoi pas. Je repars donc avec.

Installation sur Ubuntu Hardy 8.04, changement du BusID dans xorg.conf, et hop tout remarche comme avant. J'ai une configuration avec 2 écrans, configurés non pas en Twinview, mais deux screens séparés, ça me simplifie la tâche pour les jeux en full screen. Maintenant que j'ai une carte qui permet de faire du SLI, autant en profiter !

C'est donc parti pour la configuration. J'apprends dans le README que le driver ne supporte pas le multiscreen en même temps que le SLI est actif... super. Déjà l'intérêt de la GX2 devient minime. D'autre part, la SLI avec la GX2 n'est pas supporté par le driver fourni avec Ubuntu Hardy (X.org se fend d'un beau segfault quand on active le MultiGPU), il faut installer le dernier driver fourni par Nvidia à la main.

Toutefois, j'ai deux slots PCI Express. J'ai une 8600GT dans une autre machine, je la prends et je la met dans le deuxième slot. Rebelotte, édition du xorg.conf, spécification des BusID qui ont encore changé, ...

Idem. Soit c'est le SLI, soit c'est le multiscreen, même avec deux cartes différentes. Bref, j'ai ramené la 9800GX2 et je suis reparti avec une 8800GTX cette fois.

Après recherche sur Google, il semblerait possible d'activer le multiscreen et le SLI, en branchant deux cartes Nvidia (ou deux GPU sur une même carte), et une carte d'une autre marque, la limitation se situant dans le driver nvidia.

Conclusion : Nvidia, merci de faire évoluer votre driver à deux francs. A noter que la limitation est la même sur Windows, et ne concerne donc pas uniquement Linux.

Hier soir, même problème. Impossible d'obtenir une IP à nouveau. Je tente la configuration à la main, avec switch, sans switch, je repasse sur le premier port ethernet, rien n'y fait. Je sors le powerbook, et c'est parti pour les recherches sur Google.

Bref, il s'avère que le module chargé par le kernel est le R8169... un coup il marche pas, un coup il marche pour les cartes à base de R8111/R8168.

J'ai trouvé mon bonheur là : http://www.jamesonwilliams.com/hardy-r8168.html . Le post suggère d'installer le driver R8168 directement depuis le site de Realtek et propose un patch pour le kernel Hardy 2.6.24-16-generic car il ne compile pas directement.

Evidemment, vu que je n'avais pas le net sur la machine en question, le script proposé n'a pas fonctionné, j'ai donc fait le tout à la main, les instructions sont suffisamment claires .

Depuis, ça remarche.

Conclusion : APC, c'est de la merde. Prenez une autre marque. La seule fois où ce con d'onduleur aurait pu servir, l'alim de la freebox a cramé, et mon switch 3com a complètement cramé aussi. Merci, APC !

J'améliore ma fréquence de post. Seulement 4 mois depuis le précédent.

Par contre, l'utilisation de openssl pour la génération d'une autorité de certification, plus la génération des certificats pour les serveurs par la suite étant vraiment compliquée... et vu que j'ai oublié comment ça marche, les certificats SSL du serveur sont maintenant signés par CAcert, une autorité de certification indépendante.

Ca évite d'avoir à gérer la génération des certificats, et CAcert étant en voie d'adoption par plusieurs navigateurs, ça évitera dans le futur d'avoir à ajouter manuellement CAcert dans les autorités de certifications du navigateur.

PS: c'était le premier post depuis 1 an et demi, mais c'est pas grave !

Il est compatible Linux, techno line-interactive (en gros il régule le courant, mais sans passer par la batterie en permanence) donc c'est dubien (TM).