Panne du panel & accélération

Bonjour à toutes et à tous,

Suite à un problème de processus de renouvellement pour le certificat wildcar « *.lautre.net », une panne des mails pop/imap ainsi que du panel a eu lieu ce 25 juin 2020 de 8h à 11h.

Après renouvellement du certificat, les services de mail et du panel sont revenus à la normale. Aucun mail n’a du être perdu pendant cette opération

Dans ce contexte, nous avons trouvé un bug dans le code spécifique de Lautre Net dans AlternC, qui provoquait 10 à 12 secondes d’attente à chaque page du panel ! C’est désormais corrigé, et le panel decrait être beaucoup plus rapide !

HTTPS & PHP7 pour tous !

Bonjour à tous,
pour information, des mises à jour importantes ont eu lieu ces derniers jours, et la principale à l’instant 🙂 

Nginx 1.14 est désormais utilisé pour servir les pages web depuis l’Internet, en HTTP et HTTPS (depuis une semaine)on a activé le support de HTTPS pous tous, (sauf les sous-sous-domaines de lautre net comme « www.moncompte.lautre.net« , notez que « moncompte.lautre.net » marche bien )ainsi que HTTPS/2.0 et TLS1.2 & 1.3. Cela ne doit avoir aucun impact visible sur vos sites, si ce n’est un service plus rapide et plus sécurisé. Si vous souhaitez forcer HTTPS sur votre site web, assurez-vous d’avoir bien tous vos liens interne (images, css, js) en HTTPS et ajoutez les lignes suivantes dans un fichier nommé « .htaccess » à la racine de votre site : 

RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301,NE]
Header set "Content-Security-Policy" "upgrade-insecure-requests"

PHP7.0 à 7.4 sont désormais disponible à tout le monde sur le panel ! dans votre panel, si vous choisissez « ajouter un sous-domaine » ou « modifier » en face d’un sous-domaine existant, vous pouvez désormais choisir entreHebergement local PHP5.6 (la valeur par défaut) PHP7.0 ou 7.2 – 7.3 – 7.4 et dans les options avancées : PHP5.3 (uniquement pour les anciens sites, merci de ne plus l’utiliser, il sera enlevé avant la fin d’année !!) ainsi, vous pouvez, en 5 minutes, basculer votre site sur une nouvelle version de PHP, et vérifier si tout marche bien. Les Spip ou WordPress récent (< 3 ans) doivent passer sans aucun problème à PHP7.2. Pour les versions plus récentes de PHP ou plus anciennes de vos logiciels, à vous de tester 😉 

Mise à jour de l’infrastructure de Lautre Net

Bonjour, voici quelques nouvelles des évolutions en cours sur l’infrastructure de Lautre Net !

Déjà réalisé :
– migration de MySQL 5.5 à MariaDB 10.1  (on a un membre qui s’est plaint d’un « Access denied for user… », On gère 😉 ) 
– mise à jour des serveurs de mail (pop, imap, smtp) en debian Stretch, pour pouvoir avoir un meilleur antispam, une meilleure sécurité etc.

et à venir dans la semaine qui vient :  

– migration du vieil nginx qui gérait le frontal HTTP + HTTPS à une version beaucoup plus récente, qui gère : TLS1.3, HTTP2, SSL Stapling intégré (3 principes de sécurités clairement requis)et les certificats sont désormais renouvelés automatiquement, y compris pour les sous-domaines. Comptez 5 min à 1h max quand vous installez un nouveau domaine ou sous-domaine pour que son certificat soit disponible et que le HTTPS marche tout seul !(on a testé y’a 10min, mais il manquait des certificats… ce sera remis en place d’ici mercredi je pense)

– prochaine mise à jour : mise à disposition de PHP7.0 / 7.2 / 7.3 / 7.4 dans le panel d’un simple clic ! En effet, grace à php sury (Merci Ondrej, là : https://deb.sury.org/ ) on peut faire cohabiter php5.6 à 7.4 sur le même serveur ! on ne va pas se gêner ! On vous préviendra dans la semaine quand cette fonctionnalité sera arrivée.


– Installation propre de IPv6 sur tous les domaines et sous-domaines : on ajoutera à tous les domaines servis en IPv4 une IPv6 pour que ce double-protocole soit désormais bien installé chez Lautre Net !

Mise à jour des certificats SSL/TLS

Bonjour à tous,

comme certains ont pu le remarquer, nous avons mis à jour notre certificat SSL.
Pas d’inquiétude à avoir, l’ancien était juste arrivé à expiration.
L’autorité de certification pour ce certificat est Comodo, et son empreinte est : SHA1 Fingerprint=21:96:5B:C6:A4:C8:9A:4E:B0:2A:7C:A7:C8:0B:9F:9E:24:17:12:F5

Un nouveau frontal est arrivé, bienvenue effa!

Bonjour à tous et à toutes,

Nous avons mis en production un frontal supplémentaire (travail commencé il y a de nombreux mois…). Son petit nom est effa, mais ça ça ne vous interesse probablement pas.

Logiquement, vous ne devriez percevoir aucun changement, si ce n’est une amélioration des performances de vos sites. Il y a toujours un entête HTTP supplémentaire ajouté X-Frontal-Lautre pour avoir le nom du frontal qui traite votre requête, utile pour reporter des problèmes.

En cas de problème inhabituel, comme d’habitude, un mail sur aide, puis si ça ne bouge pas, un ticket, ou alors passez directement sur IRC.

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.

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.

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