Sur cette page

Exploiter Webserver-Front

Webserver-Front (FRONT) est une replique en lecture seule du Webserver que vous placez dans une DMZ ou tout reseau non fiable pour presenter les tableaux de bord et les rapports aux utilisateurs finaux — sans exposer le plan de controle interne, les sondes ni aucun secret. Cette page couvre l’exploitation au quotidien : le deploiement, la declaration du lien de replication, le demarrage et la verification de la fraicheur des donnees.

Dans cette page, ADMIN designe le Webserver normal (licencie, interne) et FRONT la replique en lecture seule. Pour l’architecture et le modele de confiance derriere FRONT, voir Webserver-Front (replique DMZ).

Quand deployer une replique FRONT

Deployez une replique FRONT lorsque vous devez publier des tableaux de bord a des personnes qui ne doivent pas atteindre le Webserver interne :

  • Pages de statut publiques ou destinees a des partenaires.
  • Tableaux de bord integres dans un portail d’entreprise situe hors de votre reseau d’administration.
  • Tout public sur un segment reseau auquel vous ne faites pas pleinement confiance.
FRONT est en lecture seule. Les utilisateurs finaux peuvent parcourir les applications, tableaux de bord, l’historique, les SLA et les cartes de decouverte, mais ne peuvent rien ajouter, modifier ou supprimer, ne peuvent pas pousser de configuration vers les composants, ni atteindre les sondes. Toute l’administration reste sur ADMIN.

Prerequis

Avant de commencer, assurez-vous de disposer de :

Prerequis Remarques
Un Webserver ADMIN licencie FRONT est alimente entierement par ADMIN ; FRONT lui-meme ne necessite aucune licence.
Un hote DMZ pour FRONT Linux ou Windows, joignable par vos utilisateurs finaux sur le port WEB.
Une route reseau ADMIN → FRONT ADMIN initie et pousse. FRONT ne se connecte jamais vers ADMIN.
Le materiel de replication Cle partagee et certificats, provisionnes hors bande (voir Configuration).

Deployer FRONT sur l’hote DMZ

  1. Placez le binaire FRONT et ses ressources d’interface sur l’hote DMZ. L’interface statique est servie depuis le disque dans le dossier ./web-front/ a cote du binaire (elle n’est pas embarquee) ; l’hote a donc besoin a la fois de l’executable et de ce dossier.

  2. Creez le fichier de configuration webserver.json a cote du binaire, puis installez-le comme service ou demon exactement comme un Webserver normal.

Linux :


# installer et demarrer le demon
./webserver_front install
./webserver_front start

Windows :


webserver_front.exe install
webserver_front.exe start

Vous pouvez l’executer au premier plan pour un premier test avec ./webserver_front run (Linux) ou webserver_front.exe run (Windows).

Configurer le lien de replication

La replication utilise deux canaux distincts ; deux reglages decrivent donc l’hote FRONT :

Reglage Signification
Point de terminaison de replication Le host:port du recepteur protege de FRONT. ADMIN y pousse les lots chiffres.
URL publique L’URL navigateur de l’interface web de FRONT (par exemple https://front.example.com:9080). Utilisee uniquement pour construire les liens d’integration qui pointent vers FRONT.

Le materiel cryptographique lui-meme (la cle partagee et les certificats) est provisionne hors bande dans webserver.json sur les deux hotes. Il ne transite jamais par le canal de replication et n’est jamais saisi dans l’interface des reglages. La liste exacte des champs figure sur la page du composant, et la generation pas a pas de la PKI ainsi que l’organisation du dossier pki/ sont couvertes dans Installer le Webserver-Front (DMZ).

Declarer FRONT depuis la page Reglages d’ADMIN

Une fois le materiel de cle en place sur les deux hotes, activez et ciblez la replication depuis ADMIN :

  1. Connectez-vous a ADMIN en tant qu’administrateur et ouvrez la page Reglages.
  2. Dans la section replication Webserver-Front, activez la replication, puis renseignez :
    • le point de terminaison de replication (recepteur FRONT host:port),
    • l’URL publique de l’interface web FRONT,
    • l’intervalle de reconciliation (frequence a laquelle ADMIN pousse un instantane complet — 5 minutes par defaut),
    • la periode de grace facultative (voir ci-dessous),
    • Accept untrusted cert, desactive par defaut : activez-le quand l’URL publique FRONT est servie avec un certificat auto-signe ou issu d’une AC interne.
  3. Cliquez sur Test pour sonder les deux adresses depuis ce serveur avant d’enregistrer, puis sur enregistrer.

Le bouton Test

Les deux adresses FRONT echouent de facons completement differentes, et aucune des deux ne se signale rapidement : un point de terminaison de replication casse laisse FRONT servir silencieusement des donnees perimees, et une URL publique cassee laisse les liens de partage de la page Utilisateurs pointer dans le vide. Test sonde les deux avec les valeurs actuellement saisies dans le formulaire — pas celles enregistrees — pour qu’une erreur soit vue avant d’etre validee.

Sonde Comment Un resultat vert signifie
Point de terminaison de replication D’abord une connexion TCP (pour qu’un mauvais host:port soit nomme comme tel), puis un vrai GET /uptime en mTLS — l’appel exact que fait la boucle de sante du sous-systeme de push la replication peut reellement circuler, poignee de main comprise
URL publique Une requete HTTP sur le port web destine aux navigateurs l’interface web FRONT est bien servie ; une redirection vers la page de connexion ou un 401 compte comme joignable, puisque cela prouve que l’interface est la

Chaque moitie rapporte ok, warn ou fail avec l’erreur sous-jacente, ce qui permet de distinguer mauvais host:port de certificat non approuve de port ouvert mais PKI de replication non provisionnee. En particulier :

  • un certificat non approuve sur l’URL publique est rapporte comme un constat, pas comme une panne — et avec Accept untrusted cert active, il devient un fait accepte plutot qu’un avertissement ;
  • le point de terminaison de replication est toujours verifie contre l’AC de replication, quoi que dise cette bascule. Y renoncer rendrait le controle mTLS vide de sens.
  • un 401/403 sur le point de terminaison de replication est un warn, pas un echec : le point de terminaison a repondu, mais cet ADMIN n’a pas ete accepte — typiquement un certificat client signe par une autre AC.

Le bouton fonctionne meme avant que la replication n’ait jamais ete activee : c’est donc utilisable comme premier controle apres provisionnement de la PKI.

Page Reglages d'ADMIN : configuration de la replication Webserver-Front

Note :

L’activation ou la desactivation de la replication s’applique immediatement a l’ADMIN en cours d’execution, mais l’effet complet (demarrage ou arret propre du sous-systeme de push) est garanti apres le prochain redemarrage d’ADMIN. Le materiel de cle de replication n’est relu qu’au demarrage — modifiez-le sur les deux hotes et redemarrez les deux.

Verifier que FRONT est actif et a jour

  1. Naviguez vers l’URL publique de FRONT et connectez-vous avec un compte utilisateur normal. Les comptes utilisateurs (et leurs empreintes de mot de passe bcrypt) sont repliques depuis ADMIN ; les memes identifiants fonctionnent donc.
  2. Verifiez que les tableaux de bord s’affichent et que l’indicateur de fraicheur montre des donnees recentes. FRONT estampille chaque lot avec la cadence de reconciliation et signale le flux comme obsolete si aucun lot n’est arrive dans un multiple de cet intervalle.
Tableau de bord en lecture seule de Webserver-Front avec indicateur de fraicheur de replication

Ce que voient les utilisateurs finaux sur FRONT

FRONT affiche les memes tableaux de bord qu’ADMIN, avec deux differences que les exploitants doivent anticiper :

  • Lecture seule partout. Les actions d’administration sont masquees ou desactivees. Aucun chemin vers les sondes, les integrateurs ou les reglages.
  • Les statuts sont aussi frais que le dernier envoi. FRONT ne contacte jamais de sonde : les statuts des applications et des moniteurs, y compris les types en direct (url, api, tcp, udp, ping, nslookup, db, sys), sont ceux calcules et repliques par ADMIN. Une application creee depuis la derniere reconciliation peut afficher brievement ses moniteurs en direct en UNKNOWN jusqu’a l’envoi suivant.
Rapport d'application sur FRONT : graphe de dependances avec les statuts repliques depuis ADMIN

Periode de grace du statut

Par defaut, FRONT affiche un changement de statut des qu’il est replique. Vous pouvez configurer une periode de grace facultative afin qu’un nouveau statut applicatif OK → non-OK soit retenu vis-a-vis des utilisateurs finaux de FRONT pendant quelques minutes apres la transition. Cela donne a l’equipe d’exploitation une courte fenetre pour reagir avant qu’une panne ne devienne visible sur un tableau de bord public.

La periode de grace n’affecte que ce que FRONT montre. Les vues temps reel propres a ADMIN, l’historique des statuts, les calculs de SLA et les alertes ne sont jamais retardes.

Exploitation au quotidien

Tache Comment
Mettre a jour l’interface FRONT (logos, ajustements de mise en page) Modifiez les fichiers sous ./web-front/ sur l’hote FRONT et rafraichissez le navigateur — aucune recompilation necessaire.
Redemarrer FRONT Utilisez les commandes service/demon (stop puis start). FRONT relit sa configuration et son materiel de cle au demarrage.
Renouveler les cles de replication Remplacez le materiel de cle sur les deux hotes hors bande, puis redemarrez les deux.
Verifier la sante du flux Surveillez l’indicateur de fraicheur sur FRONT et le statut de push sur ADMIN.

Depannage

Note :

Le flux apparait comme obsolete. ADMIN ne peut pas joindre FRONT, ou les push sont rejetes. Verifiez que la connectivite ADMIN → FRONT sur le point de terminaison de replication est ouverte, que le materiel de cle correspond sur les deux hotes et que FRONT n’a journalise aucun avertissement de demarrage signalant un materiel de replication manquant. Les push echoues sont mis en tampon sur disque cote ADMIN et reessayes automatiquement ; une breve panne se resorbe donc d’elle-meme des le retour de la connectivite.
  • FRONT journalise un avertissement marquant au demarrage. Le materiel de replication est manquant ou incomplet sur FRONT. Tant que ce n’est pas corrige, FRONT rejette chaque lot entrant et les tableaux de bord ne se mettent jamais a jour.
  • Des moniteurs en direct apparaissent en UNKNOWN. Uniquement pour une application creee depuis la derniere reconciliation : FRONT n’a pas encore sa liste d’elements repliquee et en reconstruit une sans acces aux sondes. Cela disparait a la reconciliation suivante. Si cela persiste, verifiez que la replication fonctionne (Parametres du webserver → bandeau Webserver-Front).
  • Un utilisateur ne peut pas se connecter sur FRONT. Les enregistrements utilisateurs se repliquent depuis ADMIN a chaque reconciliation. Verifiez que le compte existe sur ADMIN et qu’au moins une reconciliation a reussi depuis sa creation.

Lire le journal de replication d’ADMIN

Les push echoues sont mis en tampon sur disque cote ADMIN et reessayes par un worker de fond. Ce worker journalise un resume par cycle, et non une ligne par fichier en tampon : quand la replication est cassee, tous les elements echouent de la meme facon, et un mur d’avertissements identiques masque les trois seules choses a lire — quelle est la panne, combien est bloque, et depuis quand.

flushBufferedFrontItems - replication buffer: 0 delivered, 14 still queued, 0 discarded (of 14);
  1.2 MiB of undelivered data for front.example:8040/replicate, oldest queued 7min ago;
  HTTP 400 x14: <corps d'erreur renvoye par FRONT> ...
  • Rien du tout n’a ete livre est journalise en ERROR : la replication est en panne, pas seulement lente. Un cycle partiel donne un WARN. Un cycle qui vide la file journalise en INFO combien de push sont passes.
  • Les echecs identiques sont regroupes et comptes, avec le diagnostic complet cite une fois — y compris le corps de reponse de FRONT, car un status 400 nu ne donne rien sur quoi agir.
  • Un push abandonne correspond a des donnees que FRONT n’aura pas avant la prochaine reconciliation complete : le journal nomme donc exactement ce qui a ete perdu. La charge utile etant chiffree, les lots sont decrits par ce qu’ils transportent (nombre d’elements, instantane ou non, taille) et non par leur contenu.

Chaque rejet porte l’element a aller verifier :

Statut Signification
400 FRONT a recu le lot mais n’a pu ni le dechiffrer ni l’analyser. Presque toujours une ReplKey partagee differente entre les deux webserver.json.
401 Le jeton de replication a ete rejete : la ReplPubKey de FRONT ne correspond pas a la ReplSignKey d’ADMIN, le jeton a expire (derive d’horloge entre les hotes), ou il a ete revoque.
403 La poignee de main TLS a abouti mais la requete a ete refusee — verifiez qu’ADMIN presente bien le certificat client signe par l’AC de replication de FRONT.
404 Aucun recepteur sur ce chemin : FRONT ne tourne pas en build front, ou le point de terminaison pointe sur le port web de FRONT au lieu de son port API.
405 Le chemin existe mais n’accepte pas POST — le point de terminaison pointe tres probablement sur un port API ADMIN, pas sur un recepteur FRONT.
413 Le lot est plus gros que ce que FRONT, ou un proxy intermediaire, accepte.
502 / 503 / 504 C’est un proxy devant FRONT qui a repondu, pas FRONT. Le point de terminaison doit joindre directement le port API mTLS de FRONT.
5xx FRONT a echoue en appliquant le lot ; la raison est dans son propre webserver.log.

Note :

Des cles de replication divergentes sont la cause numero un d’un 400, et cela se tranche sans manipuler le secret. Les deux cotes journalisent, a cote du rejet, une empreinte courte et non reversible de leur ReplKey partagee : les 8 premiers caracteres hexadecimaux de son SHA-256. Comparez l’empreinte d’ADMIN avec celle que FRONT journalise a cote de sa ligne payload rejected : deux chaines de 8 caracteres, au lieu de comparer les cles a la main. La ligne d’ADMIN indique aussi si sa cle est seulement exploitable comme cle AES, une cle inutilisable echouant exactement comme une mauvaise cle.

See also

Traductions

Integrer des tableaux de bord dans un portail