Quoi de neuf chez lautre.net?

Dans un billet précédent, nous avions identifié 3 points pour les évolutions de lautre.net:

  • supprimer les IPs publiques des frontaux
  • mettre à jour AlternC (le bureau)
  • rajouter un/des serveurs MySQL

Depuis environ 2 semaines, nous avons supprimé les IPs des frontaux web. Contrairement à ce qui a été annoncé, mêmes les sites qui avaient gardé les IPs des frontaux en dur continuent de fonctionner (les répartiteurs de chargent portent encore ces adresses pour des raisons de rétro-compatibilité). Une étape de moins donc! Il nous reste à valider l’installation de nouveaux frontaux, pour passer au point suivant.

Pour ce qui est de la mise à jour d’AlternC, les avis sont partagés. D’une part, la nouvelle version d’AlternC demande plus de ressources (puisque le serveur web prend l’identité de l’utilisateur, plus de processus sont créés, entrainant une hausse de consommation). La mise à plat des frontaux permet donc de contrer ce premier argument, c’est en bon chemin.
Ensuite, la nouvelle version d’AlternC n’a pas été testé à aussi grande échelle que lautre.net. Couplé aux disponibilités décroissantes des roots, cela implique que si l’infra tombe, il sera plus difficile de diagnostiquer et corriger. C’est encore en débat donc.

Le 3ème point n’a que peu évolué, puisqu’il dépend beaucoup du précédent.

Concernant les ralentissements perçus sur l’acheminement des mails, il s’agit semble-t-il d’une recrudescence d’envoi de SPAM qui aurait provoqué cette gène. D’un point de vue système, tout est ok.

Pour ce qui est des statistiques, nous avons effectivement constaté que le robot avait cessé de fonctionner pendant quelques jours. Après un redémarrage manuel, ça semblait OK pour ce jour là. Reste à vérifier si c’est le cas. Pour ces quelques jours manquants, il se pourrait que ce soit également du à la mise à jour de l’infra, qui fausse ce jeu de stats. (mode jargon: on utilise un reverse proxy en front, qui ne relayait pas l’adresse du visiteur mais celle du proxy).

Voilà un petit peu pour ce qui se passe en ce moment. Désolé pour le manque de communication de ces derniers temps.

Mise à jour:

Deux choses.

  1. Du fait du reverse proxy (oui le truc qui a cassé les stats), vous ne pouvez plus vous fier aux IP des visiteurs dans vos htaccess. Les directives allow from <<ip>> sont donc inopérantes (pour l’instant, on travaille à résoudre cela).
  2. À cause d’une charge importante sur les machines, nous avons choisi de désactiver l’execution de programmes depuis php. Les fonctions type exec sont donc maintenant désactivées, avec effet immédiat. Espérant que cela ne perturbe pas trop vos sites (sinon, contactez-nous  )

Déménagement

Comme vous avez pu le constater, le déménagement s’est bien passé.
Avec un peu de retard, nous souhaitons remercier les membres qui étaient présents:

  • Pascal de l’Yonne Lautre
  • Léo de l’Yonne Lautre
  • Daniel de l’Yonne Lautre
  • Jean de l’Yonne Lautre
  • Benoit
  • Pierre
  • olive
  • daffy
  • fufroma
  • squidly
  • xals
  • et votre fidèle serviteur

Merci également à l’équipe de liazo pour leur accueil chaleureux.

Roadmap prévisionelle

Voici la liste des projets techniques officiels dans les tuyaux:

Supprimer les IP publiques des frontaux. Conséquence: si des gens n’utilisent pas l’IP 80.67.160.70, leur site ne fonctionnera plus.
Mettre à jour AlternC en 3.1. Conséquence: ça risque de casser beaucoup de choses, mais nous prévoyons une migration en douceur. Toute fois, il y a fort à parier que ce ne soit pas transparent. On attend donc des retours et une aide rédactionnelle pour « ce qu’il faut faire pour réparer ».
Rajout de serveur(s) MySQL. Conséquence: modifier un chouilla la conf de vos cms pour taper dans le bon.
Le reste devrait être trensparent pour vous!

Lenteurs sur la plateforme

Bonjour à tous,

un petit billet pour vous confirmer que oui, nous savons que la plateforme est lente en ce moment.
Il y a plusieurs explications, dont le serveur MySQL, ou plutôt l’usage qui en est fait.

Cependant, comme l’a dit fufroma par mail, nous avons bon espoir que la mise à jour d’AlternC améliore considérablement la situation, tout en fournissant de nouvelles fonctionnalités. Un peu de patience donc, cette mise à jour est envisagée pour la fin du mois de mars environ.

Plus de détails, plus tard. Merci!

Intervention ce vendredi 09 novembre

suite aux problèmes de performances sur les bases de données remontés par les membres,les roots on décidé de procéder à une mise à jour matérielle de l’infra.Au programme, plus de ram sur le serveur MySQL, et stocker les bases sur SSD.On en profite au passage pour augmenter la mémoire sur les frontaux.Cette intervention est planifiée pour le vendredi 9 novembre vers midi. Le programme estle suivant:

  • Mise à jour d’Elea notre serveur MySQL:
    • doublement de la mémoire vive (24G à 48G)
    • mise en place de disques SSD (Crucial M4 128G en raid1)  – la migration du stockage des bases se fera ultérieurement pour minimiser le temps de coupure
  • Mise à jour des frontaux (Emma et Ella):
    • doublement de la mémoire vive (12G à 24G)

Comment on voudrait que ça se passe: Idéalement, l’intervention devrait prendre environ 1h :

  •   Extinction des serveurs ayant besoin de Elea pour fonctionner :
    • Elsa (bureau)
    • Ella (frontal)
    • Emma (frontal)
    • Etna (mail)
    • Eyra (mail)
  • Extinction d’Elea
  • Upgrade de la ram de Elea et mise en place de ses disques SSD (estimation 30min)
  • Rallumage de Elea
  • Rallumage de Elsa, etna, eyra
  • Rajout de ram sur Ella, rallumage
  • Rajout de la ram sur Emma, rallumage

Cette mise à jour du matériel est une étape nécessaire, mais pas suffisante pourle travail de fond de mise à jour de l’infra, mais ceci sera pour un prochain épisode. On vous tiendra au courant du succès de l’intervention, mais vous pourrez avoir des infos en direct via la section « infos en temps réel » de ce blog.

Perturbations sur la plateforme

Nous vous parlions sur la liste assemblee@ de problèmes sur l’infra remonté par notre fournisseur d’accès. Et pour cause! Comme vous pouvez le voir sur l’image (le pic vers le bas), nous consommons habituellement environ 10M/s (ligne rouge), mais au moment du pic de consommation (vers 16h30) nous avons atteint quasiment 70M/s!!

Le motif a été identifié: un des site des membre a été corrompu, et a servi à mener une attaque de plus grande envergure contre (semble-t-il) un organisme bancaire.

Qu’est-ce que ça change pour nous?

À l’heure actuelle, les connexions sortantes vers des sites sécurisés (HTTPS) ont été désactivé sur les frontaux. Si vous avez des sites qui vérifient des mises à jour, où font de la syndication de contenus distants en HTTPS, ceux-ci ne fonctionneront plus. Nous attendons que le membre concerné prenne les mesures nécessaires avant de ré-ouvrir les flux.

Une petite conclusion?

Mettez à jours les logiciels que vous utilisez sur l’infra. Oh puis au passage, celle là est cadeau: essayez de penser à utiliser les ressources (rappelons le) MUTUALISÉES à bon escient… (je pense aux requêtes SQL lourdes (et bêtes (oops))).

Mise à jour de Roundcube (webmail)

Bonjour à tous,

nous avons effectué une mise à jour du webmail.
En plus d’ajouter des fonctionnalités, et de corriger des bugs, l’interface utilisateur a été repensé.

Si vous perdez vos repères, sachez que vous pouvez restaurer l’ancienne. Pour ce faire, cliquez sur «Préférences» puis dans le sous menu «Section» choisissez «Interface Utilisateur» et changez la valeur «Thème de l’interface» à «classic»

Pour rappel, le webmail est accessible via les adresses http://rc.lautre.net et https:/admin.lautre.net/rc

Mise à jour de MySQL

Salut,

On met à jour le serveur MySQL pour suivre les mise à jour de sécurité de Debian. Normalement, ça casse rien. Mais ici, ça risque de casser des choses.

Explications :
Habituellement, quand une faille est corrigé dans une version, Debian patch la version qu’il « utilise » actuellement pour profiter des corrections de failles, sans faire de changement de fonctionnalité. Ainsi, on a aucune faille, mais on ne s’est pas introduit des bugs pour des incompatibilités.

Ici, Oracle a décidé de corriger des failles sans dire lesquelles. Deux choix alors pour Debian : ne pas corriger les failles, ou bien mettre en place la « nouvelle » version de Oracle sans pouvoir valider qu’il n’y aurais pas de problème.

Debian a fait le choix de corriger les failles. Compte tenu de leur gravité, je (Fufroma) considére qu’ils ont eu raison. Reste que certains d’entre vous risque d’avoir des bugs de MySQL à partir de maintenant.

Voici la liste des problèmes qui peuvent être présent suite à la mise à jour :


mysql-5.1 (5.1.61-1) stable-security; urgency=high

Due to the non-disclosure of security patch information from Oracle,
we are forced to ship this upstream version update of MySQL 5.1 into
all releases that carry MySQL 5.1. There are several known incompatible
changes, which are listed below, taken from dev.mysql.com’s changelogs,
available here: http://dev.mysql.com/doc/refman/5.1/en/news-5-1-x.html

5.1.51:
Incompatible Change: Previously, if you flushed the logs using FLUSH
LOGS or mysqladmin flush-logs and mysqld was writing the error log to
a file (for example, if it was started with the –log-error option),
it renamed the current log file with the suffix -old, then created a
new empty log file. This had the problem that a second log-flushing
operation thus caused the original error log file to be lost unless
you saved it under a different name. For example, you could use the
following commands to save the file:
.
shell> mysqladmin flush-logs
shell> mv host_name.err-old backup-directory
.
To avoid the preceding file-loss problem, renaming no longer
occurs. The server merely closes and reopens the log file. To rename
the file, you can do so manually before flushing. Then flushing the
logs reopens a new file with the original file name. For example, you
can rename the file and create a new one using the following commands:
.
shell> mv host_name.err host_name.err-old
shell> mysqladmin flush-logs
shell> mv host_name.err-old backup-directory
.
(Bug #29751)
.
References: See also Bug #56821.

5.1.55:
Incompatible Change: When auto_increment_increment is greater than
one, values generated by a bulk insert that reaches the maximum
column value could wrap around rather producing an overflow error.
.
As a consequence of the fix, it is no longer possible for an
auto-generated value to be equal to the maximum BIGINT UNSIGNED
value. It is still possible to store that value manually, if the
column can accept it. (Bug #39828, Bug #11749800)

5.1.59:
Incompatible Change: Handling of a date-related assertion was
modified.
.
However, a consequence of this change is that several functions
become more strict when passed a DATE() function value as their
argument and reject incomplete dates with a day part of zero. These
functions are affected: CONVERT_TZ(), DATE_ADD(), DATE_SUB(),
DAYOFYEAR(), LAST_DAY(), TIMESTAMPDIFF(), TO_DAYS(), TO_SECONDS(),
WEEK(), WEEKDAY(), WEEKOFYEAR(), YEARWEEK(). Because this changes
date-handling behavior in General Availability-status series (MySQL
5.1 and 5.5), it was reverted in 5.1.62 and 5.5.21. The change is
retained in MySQL 5.6.
.
References: See also Bug #13458237.

— Clint Byrum Thu, 01 Mar 2012 23:25:34 -0800

Migration de filer2 vers Filou

Bonjour à tous,

comme annoncé par mail, nous effectuerons ce soir la migration vers le nouveau filer (si vous savez, le truc qui fait que ça va aller plus vite après). Cependant, vu la quantité de données à sauvegarder, il se peut que la plateforme soit un peu moins réactive en attendant la fin de l’intervention.
Étant donné que le premier transfert est lancé… Il est possible que vous constatiez déjà une dégradation des performances.

Nous mettrons à jour ce billet au fur et à mesure. Merci de votre compréhension.

Ps: cela n’impactera que les sites webs.

Edit: L’intervention commence, l’accès aux serveurs web ne va donc plus fonctionner.

État des lieux de l’intervention de janvier

L’intervention est terminée. Elle s’est plutôt bien déroulée. Malheureusement, nous avons constaté le lendemain des problèmes généralisés. Ils étaient en fait causés par le switch tout neuf… Après un remplacement de celui-ci, l’infra semble repartir. Des problèmes subsistent, mais les roots dorment là..

Bonjour,

l’intervention a commencé. Ce jeudi 19 janvier, les machines virtuelles ont été coupées en début de matinée.

Continuer la lecture de « État des lieux de l’intervention de janvier »