Apinc:Meeting9

Neuvième réunion des admins du serveur Jabber d'Apinc

• Quand ? Le mercredi 26 Janvier 2011 de 20h30 à 22h00
• Où ? Salon admin@chat.jabberfr.org
• Qui ? Les admins du serveur Jabber d'Apinc et les personnes souhaitant y assister sans perturber la réunion.

• Les logs de la réunion

Note : Cette page ne concerne que le serveur Jabber@Apinc, pour la réunion des admins de JabberFR, merci de consulter Jabberfr:Meeting1.

Ordre du jour

Admins

• Faire le point sur les accès que misc et moi avont, et ceux qui nous manquent encore (je pense par exemple à tout ce qui n'est pas sur apijab/apijab2 ainsi qu'à l'interface d'admin d'ejabberd et les comptes mysql).

Elghinn 30 octobre 2010 à 14:13 (UTC)

• Je m'occupe de vous donner les droits qui pourraient vous manquer Omega 26 janvier 2011 à 21:24 (UTC)

Sécurité

• Désigner un (ou plusieurs) gens responsable de l'installation des mises à jour de sécurités (il y en avait un paquet non installées sur apijab2) et des mises à jour normales. Ce qui ne veut pas dire qu'il sera le seule à pouvoir les faire.

Elghinn 30 octobre 2010 à 14:13 (UTC)

• Elghinn s'est désigné volontaire pour cette tâche Omega 26 janvier 2011 à 21:24 (UTC)

• Faire une campagne de sensibilisation sur TLS. Les utilisateurs ne devraient plus utiliser le port 5223 pour se connecter. On pourrait imaginer de faire un billet sur le blog (qui passerait par le planet). Voire même, en plus, de pourquoi pas entrer en contact directement avec ces gens (dans la mesure où on doit pouvoir savoir quels sont les comptes qui se connectent à tel ou tel c2s).

Elghinn 30 octobre 2010 à 14:13 (UTC)

• Je m'occupe de faire une annonce sur le blog pour dire en quoi c'est mieux d'utiliser starttls et le port 5222. Omega 26 janvier 2011 à 21:24 (UTC)

Migration de im2 vers prosody

• Potentielle migration vers prosody dont j'avais parlé avec omega aux JDLL. Il n'y a pour le moment rien de définitif, mais ça serait bénéfique pour nous. Tout d'abord, jabberd14 est mort et enterré, or im2 tourne encore sur jabberd14. Dernièrement jadc2s-migration a fait pas mal des siennes : il s'arrête sans prévenir en plein milieu de son travail sans laisser de trace dans les logs. Je ne compte plus le nombre de bugs qui ont déjà été signalés upstream sur jabberd14 et qui attendent toujours que quelqu'un s'y intéresse. Il y en a même qui date de l'époque où Lucas était encore là. De plus je rajouterais que im2, c'est à peine 200 utilisateurs. im2 est donc le candidat tout désigné pour commencer la migration.

Pourquoi prosody ?

• Prosody a l'avantage d'être un projet jeune, dynamique, et surtout encore maintenu.
• Facile à configurer et à prendre en main.
• Les messages d'erreur sont humainement compréhensible.
• Pas écrit en erlang.
• Très modulaire (même la gestion des <iq/>, des <presence/> et des <message/> font l'objets de modules). Il existe d'ailleurs déjà un bon nombre de modules.
• Gère PEP contrairement à jabberd14.

Actuellement, un bug lié à openssl fait que quand prosody utilise openssl, openssl consomme de plus en plus de mémoire. Openssl 1.x permettrait de corriger ce problème (mais n'est pour le moment pas disponible dans debian).

Elghinn 30 octobre 2010 à 14:13 (UTC)

• Le script de migration avance. Elghinn doit le finir vers mi-février Omega 26 janvier 2011 à 21:24 (UTC)

Documentation

• Ça serait cool si on avait un endroit où on pourrait mettre de la documentation relative au serveur. Il faudrait voir ça un peu comme un journal de bord où on y décrirait nos expériences. Voici quelques exemples :
  • Je mets à jour ejabberd, et je me rends compte qu'il y a un code secret à taper tout en faisant une chorégraphie, et tout ceci dans un ordre bien précis au millimètre près → Je le documente
  • J'aimerai bien pouvoir aider Mme Michou qui veut qu'on ajoute son domaine mme.michou.com à im2. → Je vais chercher dans la documentation le mail type à lui envoyer pour lui expliquer la procédure, et j'en profite pour me remémorer de ce que moi j'ai à faire du côté de im2.
  • Quand on met à jour mediawiki, je sais qu'il y a toute une suite de chose à faire en plus de la mise à jour en elle même (comme réappliquer les quelques patchs qu'on a) → Je le documente
  • Et tout ce qu'on jugera utile de documenter

Il y a plusieurs raison qui justifie la création d'une telle documentation :

• Permet de ne rien oublier (combien de fois avez-vous du trifouiller avant de retrouver la démarche/syntaxe exacte pour telle ou telle opération ?)
• Permet le partage d'information au sein de l'équipe déjà en place (comme ça on évite d'être trop dépendant d'une personne en particulier, surtout quand elle part en vacances)
• Permet de passer simplement le savoir à de nouveaux venus (comme misc et moi par exemple)
• Permet de centraliser la documentation, plutôt que de la voir éparpiller aux quatre coins du serveur jusqu'à oublier qu'elle existe pour retomber dessus pas hasard 6 mois plus tard.

De plus j'ajouterai que cette documentation serait créée au fur et à mesure, et n'aurait rien de formelle. L'important est avant tout qu'elle documente/informe sur certains aspects de notre « travail ». Donc pas besoin que ça soit beau ni de vulgariser comme si on parlait à un enduser. Elle s'adresse avant tout à nous. D'ailleurs, elle n'a pas forcément à être publique (bien que ça pourrait être cool que d'autres puissent profiter de notre expérience si cela est possible).

Elghinn 25 janvier 2011 à 23:35 (UTC)

• Misc s'occupe de créer un dépôt git sur le serveur où l'on placera toutes nos documentations, ainsi que les patchs utilisés en interne. Omega 26 janvier 2011 à 21:24 (UTC)

Virtual hosting

• Actuellement, 88 domaines n'ont pas les bons enregistrements DNS. Pour la plupart il s'agit juste d'un problème de configuration. Pour d'autres, le domaine n'existe tout simplement plus. Il faudrait automatiser ce genre de vérification, et accessoirement automatiser la suppression des domaines n'existant plus ainsi que l'envoi de mail pour les mauvaises configs (en mettant jabber@apinc en copie). Ceci afin d'avoir une liste la plus à jour possible sans que cela nous demande trop de travail.

Elghinn 30 octobre 2010 à 14:13 (UTC)

• J'ai fait un petit recensement des domaines ne marchant pas, en fait on a 72 domaines qui ne sont pas à jour (dont jabber.fr :/). La plupart étant soit que le domaine n'existe plus, soit qu'il ne pointe pas vers chez nous. Il y a également 11 domaines qui pointent encore vers im.apinc.org (alors que ça fait un moment qu'on a migré vers im2). Et il y a 8 domaines dont l'IP pointe encore vers celle d'im2 avant la migration. Je pense qu'on devrait supprimer tous les domaines dont le DNS ne marche plus ou pointe vers autre chose (même punition pour les domaines qui pointent encore vers im.apinc.org). Pour les 8 domaines qui pointent vers l'ancienne IP je vais leur faire un mail.

Pour ce qui est de l'automatisation, on a déjà un script dans nettoyage/listDomaine.py qui fait les vérifications, il faut juste l'adapter un peu.

Omega 1 novembre 2010 à 14:29 (UTC)

• Un ménage a été fait il y a un mois. Il reste trois domaines qui pointent encore vers l'ancienne IP de im2.apinc.org. Je m'occupe de les relancer. Omega 26 janvier 2011 à 21:24 (UTC)

apijab2

• Utilité actuelle de apijab2.

Elghinn 30 octobre 2010 à 14:13 (UTC)

• Discuter du passage de apijab2 de oldoldstable (etch) à stable (lenny), voire testing (squeeze)

Elghinn 30 octobre 2010 à 14:13 (UTC)

• Fût un temps, apijab2 servait de roue de secours quand apijab avait un soucis. J'ai pu me rendre compte que ce n'était plus le cas. Veut-on que ça soit de nouveau le cas ? apijab2 peut-il encore assumer ce rôle en terme de dimension ? J'ai cru lire quelque part dans ~/doc/ qu'il y avait un cron pour synchroniser apijab et apijab2 (enfin, plutôt faire un bakcup de apijab sur apijab2 et un backup de apijab2 sur apijab). Fonctionne-t-il encore ?

Elghinn 30 octobre 2010 à 14:13 (UTC)

• Le backup croisé entre apijab et apijab2 fonctionne toujours. Par contre effectivement on ne pourra surement pas redémarrer ejabberd sur apijab2 en cas de problème. Je pense qu'on ne devrait plus trop se soucier d'apijab2, et même éventuellement reprendre son IP pour mettre une des machines de remplacement qu'on devrait avoir bientôt (et si on peut avoir deux machines on pourrait faire un cluster, ça serait bien). Omega 31 octobre 2010 à 19:09 (UTC)

• apijab2 ne sert plus à rien pour l'instant. Omega 26 janvier 2011 à 21:24 (UTC)

Ajout de nouveaux services

• Je trouve que le serveur manque un peu de service propre à lui, le problème c'est qu'on a toujours voulu donner tous les services qu'on pouvait à JabberFR plutôt que de faire des services que pour nous, maintenant on peut se poser la question de l'intérêt. Par exemple la passerelle IRC et le proxy n'ont peut-être pas entièrement leur place sur JabberFR (mais on ne peut plus vraiment les enlever maintenant). Peut-être est-ce qu'il faudrait mieux faire plus de services exclusivement pour Jabber@Apinc. Exemples de services :

• Redirection de Mails : rediriger les mails arrivant sur une adresse jabber vers une vrai adresse mail. On en a déjà parlé, ça ne semble pas insurmontable à faire à une choses près : il faut que les enregistrement MX des serveurs pointent chez nous (facile pour im.apinc.org, plus dur pour les autres).
• Passerelle RSS : je sais pas si c'est vraiment très pertinent, mais ça pourrait être sympa de mettre un truc genre jabrss.

Omega 7 septembre 2008 à 15:58 (UTC)

Avec les flux de planet IM, et de jabberfr, ou de jabber apinc :) cdubouloz 9 septembre 2008 à 17:30 (UTC)

• Pour l'instant on va se concentrer sur la stabilisation du serveur Jabber. Omega 26 janvier 2011 à 21:24 (UTC)

Questions du Public

• Nous allons étudier la question d'installer Jappix comme client léger en remplacement de JWChat. Omega 26 janvier 2011 à 21:24 (UTC)

Nom du nouveau serveur

Plusieurs propositions, notamment :

• clouteuz
• tronçonneuz
• débrousailleuz
• moissoneuz
• ensileuz
• decapeuz
• surfaceuz
• koineuz
• fraiseuz
• decalamineuz
• rétrocaveuz
• paveuz
• raleuz
• tronconneuz
• picoleuz
• rétrocaveuz
• moissonneuz
• medicamenteuz
• automitrailleuz

Finalement le nom qui a été retenu est fraiseuz. Omega 26 janvier 2011 à 21:24 (UTC)