[INFO] suivi et évolution du serveur

Un problème sur le forum ? Des suggestions ou idées, c'est ici !
Avatar de l’utilisateur
schwomp
Membre à vie du GPZ Dream Team :D
Membre à vie du GPZ Dream Team :D
Moto(s) : SV 650 S (un bi qu'il est bien !)
Signe particulier : Intégriste (mais j'me soigne...)
Localisation : Quimper
Messages : 2816
Inscription : 31 déc. 1976, 22:59

20 mai 2018, 05:28

Hello Denis ! :)

dnstouron a écrit :Tu bosses toujours aussi bien et de manière de plus en plus professionnel :siffle: :super:

Merci pour le compliment !

Cependant, la méthode actuelle reste empirique...

Aujourd'hui j'installe un simple Wordpress sur la plate-forme et, pour le thème, il faut juste uploader un fichier de 8 Mo (le ZIP du thème)

Le verdict tombe, implacable : connexion interrompue au bout de 45/50 secondes.

Forcément, #SPA_NORMAL !

Donc, direction la conf d'Apache, Varnish, H2O et PHP pour chercher où est ce #PU@#T~AIN de paramètre concernant le timeout qui bloque l'upload.

Deux heures plus tard, las, j'essaye avec Chrome.

Ce navigateur n'est pas meilleur mais contrairement à mon Firefox qui est bardé de plugins afin de protéger ma vie privée, Chrome est "full stock".

Entre-temps mais trop tardivement, j'ai utilisé "tcpdump" pour savoir finalement qui envoyait un paquet "RST" ou "FIN" pour interrompre la connexion.

Verdict : ça marche avec Chrome (#LASSITUDE...)

Donc je reprends mon Firefox en mode "debug" (aucun plugin actif) : idem; ça marche également.

Tout ça pour dire que :

1) je ne suis pas vraiment doué quand il s'agit de repérer un bug
2) un sysadmin plus averti/blasé ou déjà rompu à l'exercice sera plus efficace

Reste à savoir quel est le "facheux" plugin de Firefox qui coupait la connexion (on verra çà plus tard...)

dnstouron a écrit :Sinon sur mon smartphone régulièrement ( uniquement quand je suis en wifi de chez moi avec les DNS orange ) j'ai encore de DNS error nom de domaine inconnus ... puis ça remarche ...

Concernant les DNS sur ces derniers jours, c'était plutôt la pagaille...

Le TTL des serveurs de noms était d'une heure donc j'ai fait les changements tranquillement.

Sauf que, et c'est la seconde fois que je m'en rends compte, certains serveurs DNS cache ne tiennent pas compte d'un timing aussi court.

Solution : Patienter encore 12 heures et la propagation sera complète.

A l'avenir je vais me débrouiller, #PROMIS_JURÉ_CRACHÉ, pour qu'il n'y ait plus de cafouillages lié aux DNS.

A+
Avatar de l’utilisateur
dnstouron
Modérateur
Modérateur
Contact :
Moto(s) : ZZR1100 D1 & GPZ500-E10
Signe particulier : regardez mon avatar :)
Localisation : A la campagne dans 28 proche Dreux
Messages : 7572
Inscription : 16 mai 2010, 17:36

Re: [INFO] suivi et évolution du serveur

23 mai 2018, 16:29

tu as dû faire des modifications les URL dans les mails sont ... originaux :siffle:
ImageImage
ZZR un jour, ZZR toujours
Club des 100 000
POST PouAaAAAAaaaa !!!
Avatar de l’utilisateur
schwomp
Membre à vie du GPZ Dream Team :D
Membre à vie du GPZ Dream Team :D
Moto(s) : SV 650 S (un bi qu'il est bien !)
Signe particulier : Intégriste (mais j'me soigne...)
Localisation : Quimper
Messages : 2816
Inscription : 31 déc. 1976, 22:59

Re: [INFO] suivi et évolution du serveur

23 mai 2018, 16:36

Plop ! :D

Non, pas de modifs dans les mails pour l'instant.

C'est quoi le souci ?

A+
Avatar de l’utilisateur
dnstouron
Modérateur
Modérateur
Contact :
Moto(s) : ZZR1100 D1 & GPZ500-E10
Signe particulier : regardez mon avatar :)
Localisation : A la campagne dans 28 proche Dreux
Messages : 7572
Inscription : 16 mai 2010, 17:36

Re: [INFO] suivi et évolution du serveur

23 mai 2018, 17:43

je reçois ça comme notification avec le lien : http://gpzdreamteam.pepitransport.com/l ... BdEwECUw==

au depart j'ai hésité avec l'URL différente de forum.gpzdreamteam.com vue que je me fais spamer ...
ImageImage
ZZR un jour, ZZR toujours
Club des 100 000
POST PouAaAAAAaaaa !!!
Avatar de l’utilisateur
schwomp
Membre à vie du GPZ Dream Team :D
Membre à vie du GPZ Dream Team :D
Moto(s) : SV 650 S (un bi qu'il est bien !)
Signe particulier : Intégriste (mais j'me soigne...)
Localisation : Quimper
Messages : 2816
Inscription : 31 déc. 1976, 22:59

Re: [INFO] suivi et évolution du serveur

23 mai 2018, 17:48

Compris.

C'est "Pepipost" qui ne respecte pas les paramètres que j'ai indiqué dans leur panneau de config.

Ils ont activé le tracking des liens contenus dans les mails alors que j'ai expressément demandé le contraire...

Je vais regarder.

Merci pour l'info !

A+
Avatar de l’utilisateur
schwomp
Membre à vie du GPZ Dream Team :D
Membre à vie du GPZ Dream Team :D
Moto(s) : SV 650 S (un bi qu'il est bien !)
Signe particulier : Intégriste (mais j'me soigne...)
Localisation : Quimper
Messages : 2816
Inscription : 31 déc. 1976, 22:59

Re: [INFO] suivi et évolution du serveur

01 juin 2018, 21:43

Fin des turbulences, merci de détacher votre ceinture, tout est OK

Petit résumé :

1) Le nouveau "cluster" web qui devait accueillir tous les projets libres/associatif/autres est désormais stable et validé
2) Le forum GPZ Dream Team l'utilise depuis quelques jours, RAS, migration sans aucun souci
3) Nos copains du Forum ER5 nous ont également rejoint et utilisent cette même plate-forme

Description technique :

La nouvelle plate-forme repose sur 11 containers OpenVZ.

(Ce que j'appelle par fainéantise un "cluster" est un ensemble de containers car ils sont tous liés entre-eux via un sous-réseau interne).

Chaque container à sa propre tâche (DNS, SQL, SMTP, IMAP, HTTP, PROXY, SSL, VPN, Monitoring, etc).

Toutes ces machine virtuelles tournent sous Debian 9 (Stretch) mais systemd a été désactivé au profit de sysvinit.

La raison est simple : le kernel OpenVZ du système hôte ne permet pas de restaurer correctement des backups "live" (données + mémoire) des containers OpenVZ utilisant systemd.

Dans la pratique cela ne change rien : Debian 9 supporte systemd et sysinit.

Donc utiliser l'un ou l'autre n'a, pour l'instant, aucune importance.

Note: concernant les "nerds/sysadmins/rageux" qui pensent (à juste titre) que Debian n'est pas une distribution "Top-Of-The-Edge", oui, merci, je suis au courrant. :wink:

Mon but n'est pas de proposer les dernières versions bêta à la mode mais d'utiliser en production des versions de logiciels qui ont été testés/vérifiées et qui sont donc stables.

Principales nouveautés/améliorations :

- HTTP 2
- TLS (note: A+)
- MariaDB 10
- PHP 7

Pour faire court (j'ai omis tous les autres logiciels connexes), la plate-forme est à jour.

Est-ce que cela change pour moi (en terme de vitesse) dans ma vie de tous les jours ?

1) si vous êtes en ville et disposez de la fibre, du VDSL ou de l'ADSL, la réponse est non
2) si vous êtes en rase campagne avec une connexion ADSL "moisie", la réponse est oui

Le protocole HTTP2 permet de supprimer la latence lors de la réception des différents contenus (CSS, JS, Images, etc).

Est-ce que cela change pour moi (en terme de sécurité) dans ma vie de tous les jours ?

Oui.

Désormais vous accédez au forum "GPZ Dream Team" avec le niveau de sécurité maximal (TLS) autorisé par votre navigateur.

Seuls les protocoles de chiffrements "corrects" sont acceptés : tout autre tentative plus "faible" sera refusée.

Est-ce que cela change pour moi (en terme de RGPD) dans ma vie de tous les jours ?

Très honnêtement, je ne me suis pas encore plongé profondément dans les documents de la RGPD (c'est dans ma todo-list !).

Mais vous êtes entre de bonnes mains car voici ce qui est en vigueur depuis plusieurs années sur le forum :

1) vos données personnelles ne sont pas partagées/divulgués/transmises à des tiers (je tiens tout comme vous à mon email "perso" et je n'ai aucune envie de recevoir du spam)
2) votre mot de passe est chiffré, inutile de le demander à un modérateur/administrateur : il ne peut en aucun cas le connaitre (demandez un nouveau MDP depuis l'interface du forum)
3) votre droit à l'oubli est respecté : demandez la suppression de votre compte (à un admin) et tous vos messages seront détruits

A+
Avatar de l’utilisateur
guiguibu49
Essoreur de poignée
Essoreur de poignée
Moto(s) : 500 Gpz post
Messages : 485
Inscription : 26 sept. 2016, 16:24

Re: [INFO] suivi et évolution du serveur

01 juin 2018, 22:11

C'est pour ça que les lien des mail ne sont plus exploitable depuis quelque jours ?

Sinon jamais eu de problème de dns moi :)
Merci pour le taf réalisé pour nous :kiss:
Avatar de l’utilisateur
schwomp
Membre à vie du GPZ Dream Team :D
Membre à vie du GPZ Dream Team :D
Moto(s) : SV 650 S (un bi qu'il est bien !)
Signe particulier : Intégriste (mais j'me soigne...)
Localisation : Quimper
Messages : 2816
Inscription : 31 déc. 1976, 22:59

Re: [INFO] suivi et évolution du serveur

07 août 2018, 01:26

Application consistent snapshot VS crash consistent backups

Cherchez pas trop loin, il y a une grosse dose d'enfumage (côté marketing) concernant ces deux termes. :roll:

Note : ceux qui se rappellent du "PUSH MAIL" sur les mobiles BlackBerry, levez la main !
(Ou comment réussir à facturer de manière éhonté le protocole IMAP...)

Bref !

Le souci est le suivant :

1) les bases de données sont gérées par la machine virtuelle A
2) les fichiers des sites internet sont gérés par la machine virtuelle B

Objectif : obtenir des sauvegardes cohérentes pour les données de A et B.

Le downtime c'est mauvais pour le karma :

1) car faire des sauvegardes à chaud, c'est possible
2) mais comment (re)synchroniser trois sous-ensembles différents (fichiers, mémoire et connexions réseau)

Objectif intermédiaire : trouver une solution genre "#SPA_MAL_!" (pour la perfection on verra ça plus tard...)

Plusieurs pistes mais j'ai pas encore creusé le sujet...

Donc si vous avez des idées, elles sont les bienvenues ! :wink:

Est-ce qu'il y aurait un/des matheux dans la place ?

Si oui, l'équation semble, au premier abord, relativement "simple" (mais comme je suis une sombre buse en maths, je suis sûr de me tromper...).

Sachant que les ensembles A et B sont interconnectés (la synchronisation des données est cependant asynchrone), comment obtenir un snapshot (une vue atomique) de ces deux ensembles à un instant T ?

Ou plus précisément, si cela n'était pas possible, quel ensemble (A ou B) devrait être prioritaire ?

Note : si je formule mal la problématique, c'est normal... BTS Info avec succès mais ingénieur j'ai pas tenté le coup... :mrgreen:

A+
Avatar de l’utilisateur
dnstouron
Modérateur
Modérateur
Contact :
Moto(s) : ZZR1100 D1 & GPZ500-E10
Signe particulier : regardez mon avatar :)
Localisation : A la campagne dans 28 proche Dreux
Messages : 7572
Inscription : 16 mai 2010, 17:36

Re: [INFO] suivi et évolution du serveur

20 août 2018, 10:50

Le point critique est la base de données donc les VM de type A
Le crash consistant / snapshot est pas le top même si ton moteur de BDD (MariaDB de mémoire) est plutôt pas mal et robuste à ce type de sécurisation des données
les VM de type B sont relativement statique ( si ce n'est l'upload des images dans la galerie ) et les fichiers en cache ( PHPBB ou autre fonctionnalité mise en place )

Le plus compliqué pour toi devrait être les tables qui gères les images de la galerie car il ne faudrait pas que ta sauvegarde de base et la sauvegarde des fichiers images soient trop décalés sous peine lors de la restauration d'avoir des fichiers images qui n'existeraient pas en base de données ( l'inverse est pas possible du fait du fonctionnement de ta galerie ) .

Je n'ai pas souvenir que la virtualisation sous les hôtes de type Unix ou BSD permette d'avoir des snapshot de BDD consistant à chaud
L'idéal pour toi serait de planifier un export BDD au format SQL ou autre tous les jour à un heure précise de tes BDD et de planifier au même moment un snapshot de tes VMs de type B
L’export même rapide n'est pas instantanée mais les fonctionnalités des moteurs de BDD permettent de faire ces opérations sans interruption de service
IL ne te restera plus qu'a faire l'opération de snpashot de ta VM A quand tu veux après la fin de l'export de ta BDD

A la restauration de tes environnements il ne faudra pas repartir avec les fichiers SQL ouverts au moment de ta sauvegarde mais restaurer l'export contenue dans ta VM de type A avant de redémarrer ta production

Je ne sais pas si je suis claire dans mes explications surtout après 3 semaines de vacances informatique :mrgreen:
ImageImage
ZZR un jour, ZZR toujours
Club des 100 000
POST PouAaAAAAaaaa !!!
Avatar de l’utilisateur
schwomp
Membre à vie du GPZ Dream Team :D
Membre à vie du GPZ Dream Team :D
Moto(s) : SV 650 S (un bi qu'il est bien !)
Signe particulier : Intégriste (mais j'me soigne...)
Localisation : Quimper
Messages : 2816
Inscription : 31 déc. 1976, 22:59

Re: [INFO] suivi et évolution du serveur

22 août 2018, 01:10

Hello Denis ! :D

dnstouron a écrit :Je ne sais pas si je suis clair dans mes explications surtout après 3 semaines de vacances informatique :mrgreen:

Je peux te confirmer, sans le moindre doute, que ton oeil est toujours aussi aiguisé ! :wink:

Réponse détaillée un peu plus tard et en détail car plusieurs concepts s'entrechoquent.

dnstouron a écrit :A la restauration de tes environnements [...]

C'est exactement ce point qui me pose problème...

Faire des sauvegardes synchronisées de plusieurs containers (A : BDD & B : WEB), c'est déjà en place : backups complets (données, état complet de la mémoire, sockets, etc).

Sauf que, lors d'une restauration, les différents timeout UDP/TCP entrent dans le bal...

Concernant UDP, c'est mort : un paquet émis et non traité => poubelle.

TCP est autrement plus pugnace (dans le bon sens du terme) car il va retenter l'échange jusqu'au timeout.

Et, bonne nouvelle, c'est l'unique point d'échange entre les containers A (MariaDB) & B (PHP) et vice versa.

Denis, je peux me tromper mais, à priori, ta réponse m'a apporté la bonne indication. MERCI ! :D

J'y réfléchis 24/48 heures et je poste à nouveau.

A+
Avatar de l’utilisateur
schwomp
Membre à vie du GPZ Dream Team :D
Membre à vie du GPZ Dream Team :D
Moto(s) : SV 650 S (un bi qu'il est bien !)
Signe particulier : Intégriste (mais j'me soigne...)
Localisation : Quimper
Messages : 2816
Inscription : 31 déc. 1976, 22:59

Re: [INFO] suivi et évolution du serveur

26 août 2018, 01:46

Un kernel panic c'est moche, deux kernel panic c'est trop...

Mercredi 22 août, vers 2 heures du matin, j'ai relancé certains serveurs avec le dernier noyau OpenVZ "Legacy" : 2.6.32-openvz-042stab133.1-amd64.

Toujours le 22 août vers 9h30, je reçois une flopée de mails m'indiquant un souci de "connectivité" concernant le forum et d'autres sites.

Jusqu'ici tout va "bien" (façon de parler...) : le serveur concerné a rebooté #TOUT_SEUL_COMME_UN_GRAND et les différents services ont repris leurs activités.

Deux jours plus tard, le vendredi 24 août vers 18h45, rebelote : kernel panic et reboot dans la foulée.

Donc, soit il y a un problème hardware, soit le kernel pose problème.

Même jour (vendredi 24 août), je décide donc de "rétropédaler" vers le noyau précédent vers 22h50.

Et, jusqu'à présent, tout est stable.

En résumé, pour chaque reboot (inopiné ou souhaité) : 5 à 7 minutes de downtime.

Plus d'infos ici :

- Unable to handle kernel NULL pointer dereference
- Crash kernel 2.6.32-042stab133.1

Bonne nouvelle, le bug va être rapidement corrigé.

Autre bonne nouvelle, la faille "TLBleed" renommée en "L1TF" n'est, à priori, pas d'actualité sur le serveur qui héberge le forum GPZ (et nos copains en ER5).

Pour une raison simple : il n'y a que des VPS que j'administre personnellement ou des VPS dont j'assure l'infogérance (personnes de confiance donc pas de stress).

- TLBleed
- faille L1TF sur les processeurs Intel

A+

Revenir vers « Fonctionnement du forum »

Qui est en ligne ?

Utilisateurs parcourant ce forum : Aucun utilisateur inscrit et 0 invité