Skip to main content

Diagnostiquer un serveur relais Medulla

Les serveurs relais Medulla assurent l'intermédiaire entre le serveur Medulla principal et les machines clientes.

Ils sont notamment impliqués dans la distribution des ordres et des packages vers les machines qui leur sont associées.

Lorsqu'un relais rencontre un problème, les symptômes peuvent être :

  • des machines qui ne peuvent plus recevoir de déploiements ;
  • des packages qui ne sont pas disponibles sur certaines machines ;
  • des erreurs ABORT RELAY DOWN ;
  • des erreurs ABORT ALTERNATIVE RELAYS DOWN ;
  • des erreurs ABORT INFO RELAY MISSING ;
  • des machines associées à un relais qui n'existe plus ;
  • un problème de synchronisation des packages.

Information :
Un serveur relais Medulla contient notamment un serveur XMPP, un agent relais et un serveur Guacamole. Le diagnostic doit donc permettre de distinguer un problème d'accessibilité du serveur, d'enregistrement du relais, d'affectation des machines ou de distribution des packages.

1. Identifier le symptôme

Commencez par déterminer si le problème concerne :

Symptôme Diagnostic prioritaire
ABORT RELAY DOWN Vérifier que le relais existe et qu'il est accessible
ABORT ALTERNATIVE RELAYS DOWN Vérifier les relais alternatifs disponibles
ABORT INFO RELAY MISSING Vérifier l'affectation du relais à la machine
Une seule machine ne fonctionne pas Vérifier son champ groupdeploy et sa règle d'affectation
Toutes les machines d'un relais sont impactées Vérifier en priorité le relais lui-même
Un package est absent sur un relais Vérifier la distribution et la synchronisation du package

2. Vérifier que le serveur relais est accessible

Lors d'une erreur :

ABORT RELAY DOWN

le document d'exploitation indique que le relais peut être éteint ou ne plus exister.

Commencez par tester son accessibilité réseau :

ping IP_DU_RELAIS

Puis, si l'accès SSH est autorisé :

ssh root@IP_DU_RELAIS

Remarque :
L'absence de réponse au ping ne permet pas à elle seule de conclure que le serveur est arrêté, certains environnements pouvant filtrer ICMP. Le test SSH permet de compléter le diagnostic.

Si le relais est inaccessible, vérifiez :

  • qu'il est allumé ;
  • que son adresse IP est correcte ;
  • que le routage entre le serveur principal et le relais fonctionne ;
  • que les flux nécessaires ne sont pas bloqués.

3. Vérifier le dernier état connu du relais

Si le relais ne répond pas, consultez son dernier état enregistré dans Medulla :

SELECT *
FROM uptime_machine
WHERE hostname = "NOM_DU_RELAIS"
ORDER BY id DESC
LIMIT 1\G;

Le champ status indique son dernier état connu :

  • 1 : considéré comme en ligne ;
  • 0 : considéré comme hors ligne.

Le champ updowntime permet de connaître la durée pendant laquelle le relais est resté dans cet état.

4. Vérifier que le relais est toujours déclaré et activé

Pour afficher les relais connus par Medulla :

SELECT id, nameserver, enabled
FROM relayserver;

Vérifiez notamment :

  • que le relais concerné apparaît dans la liste ;
  • que son nom correspond bien au serveur attendu ;
  • la valeur de son champ enabled.

Lorsque :

enabled = 1

le document d'exploitation indique que ce relais peut être fourni aux machines par le substitut assessor.

Attention :
Un relais qui n'existe plus mais qui reste activé dans la configuration peut continuer à être proposé aux machines et provoquer des erreurs de déploiement.

5. Cas d'un relais qui n'existe plus

Si vous avez confirmé qu'un relais a été définitivement supprimé ou n'est plus utilisé, le document d'exploitation fournit la commande suivante pour le désactiver :

UPDATE relayserver
SET enabled = 0
WHERE id = <id_du_relais>;

Il indique également de vérifier l'entrée correspondante dans la table machines :

SELECT id, enabled
FROM machines
WHERE hostname = 'NOM_DU_RELAIS';

Puis, si le serveur est effectivement retiré :

UPDATE machines
SET enabled = 0
WHERE id = <id>;

Attention :
Ces commandes modifient directement la base Medulla. Elles doivent uniquement être utilisées lorsqu'il a été confirmé que le relais est définitivement retiré, après sauvegarde de la base de données.

6. Diagnostiquer ABORT RELAY DOWN

Le statut :

ABORT RELAY DOWN

indique que Medulla ne peut pas utiliser le relais prévu pour le déploiement.

Effectuez les contrôles suivants :

  1. tester le relais avec ping ;
  2. tester son accès SSH ;
  3. vérifier son dernier état dans uptime_machine ;
  4. vérifier sa présence dans relayserver ;
  5. vérifier la valeur de enabled ;
  6. si le relais a été supprimé, vérifier qu'il n'est plus proposé aux machines.

7. Diagnostiquer ABORT ALTERNATIVE RELAYS DOWN

Le statut :

ABORT ALTERNATIVE RELAYS DOWN

signifie qu'aucun des relais alternatifs utilisables n'est disponible.

Le document d'exploitation recommande dans ce cas de vérifier les relais.

Pour chacun des relais susceptibles d'être utilisés :

  • vérifiez son accessibilité réseau ;
  • vérifiez son dernier état connu ;
  • vérifiez qu'il est toujours activé dans relayserver.

Information :
Si plusieurs relais deviennent indisponibles simultanément, recherchez également un problème commun de réseau ou d'infrastructure plutôt qu'une panne individuelle de chaque relais.

8. Diagnostiquer ABORT INFO RELAY MISSING

Le statut :

ABORT INFO RELAY MISSING

indique que les informations concernant le relais associé à la machine sont absentes.

Le document d'exploitation donne notamment comme cas possible :

  • un relais supprimé après avoir été attribué à la machine ;
  • une machine dont le champ groupdeploy n'est pas renseigné.

Le champ :

groupdeploy

de la table machines contient le JID du relais associé à la machine.

Vérifiez donc que la machine possède bien une valeur groupdeploy.

Par exemple :

SELECT id, hostname, groupdeploy
FROM machines
WHERE hostname = 'NOM_DE_LA_MACHINE';

Si groupdeploy est vide, la machine n'est associée à aucun relais.

9. Vérifier que le relais indiqué dans groupdeploy existe

Une valeur présente dans groupdeploy n'est pas suffisante : elle doit correspondre à un relais qui existe toujours.

Affichez les relais disponibles :

SELECT id, nameserver, jid, enabled
FROM relayserver;

Comparez ensuite le JID du relais avec la valeur groupdeploy de la machine.

Attention :
Si groupdeploy référence un ancien relais qui a été supprimé, Medulla peut retourner ABORT INFO RELAY MISSING.

10. Corriger une machine sans relais associé

Après avoir identifié le relais correct, le document d'exploitation fournit comme exemple :

UPDATE machines
SET groupdeploy = 'agent@medulla-interne/mainrelay'
WHERE id = <id_machine>;

La valeur utilisée doit correspondre au JID du relais approprié présent dans la table relayserver.

Attention :
Cette requête modifie directement l'affectation d'une machine. Elle ne doit pas être appliquée sans avoir auparavant identifié la raison pour laquelle l'affectation automatique n'a pas fonctionné. Dans le cas contraire, le problème risque de se reproduire lors d'une prochaine reconfiguration.

11. Vérifier la règle d'attribution du relais

Medulla peut attribuer les machines à un relais en fonction de règles réseau.

Le document d'exploitation fournit un exemple permettant de tester si un subnet correspond à une expression régulière définie dans les règles d'attribution :

SELECT '10.10.19.0/24'
REGEXP '^10\.62\.19\.0\/24$';

Dans cet exemple :

  • 10.10.19.0/24 correspond au subnet de la machine ;
  • ^10\.62\.19\.0\/24$ correspond à la règle à tester.

Le résultat permet de déterminer si le subnet correspond ou non à la règle.

Conseil :
Si plusieurs machines d'un même réseau sont affectées au mauvais relais, recherchez en priorité une erreur dans la règle d'attribution plutôt qu'une anomalie individuelle sur chaque machine.

12. Vérifier les informations réseau de la machine

Pour comprendre pourquoi une machine reçoit ou non un relais particulier, vous pouvez afficher ses informations réseau connues par Medulla :

SELECT
    m.hostname,
    m.ippublic,
    m.ip_xmpp,
    m.macaddress AS machine_mac,
    n.ipaddress AS network_ip,
    n.broadcast,
    n.gateway,
    n.mask,
    n.mac AS network_mac
FROM xmppmaster.machines AS m
INNER JOIN xmppmaster.network AS n
    ON n.machines_id = m.id
WHERE m.hostname = 'NOM_DE_LA_MACHINE';

Vérifiez notamment que le réseau remonté par la machine correspond au réseau attendu par la règle d'attribution du relais.

13. Identifier les relais sans aucune machine associée

Pour lister les relais qui n'ont aucun client associé, le document d'exploitation fournit la requête suivante :

SELECT nameserver
FROM relayserver
WHERE relayserver.jid NOT IN (
    SELECT groupdeploy
    FROM machines
    WHERE agenttype = 'machine'
);

Cette requête permet d'identifier les relais actuellement déclarés mais qui ne sont utilisés par aucune machine.

Information :
Un relais sans client n'est pas nécessairement en erreur. Il peut avoir été installé en prévision d'un nouveau site ou être utilisé comme relais alternatif. Cette requête doit donc être interprétée dans le contexte de l'architecture.

14. Vérifier la disponibilité des packages sur le relais

Lorsqu'un relais est accessible mais qu'un package ne peut pas être déployé, vérifiez que le package est disponible sur le serveur utilisé pour sa distribution.

Une erreur telle que :

Transfer error: Package Server does not have this package

indique que le serveur de packages utilisé ne dispose pas du package demandé.

Dans cette situation, le problème ne signifie pas nécessairement que le relais lui-même est hors ligne.

Il faut distinguer :

Erreur Interprétation
ABORT RELAY DOWN Le relais n'est pas disponible
ERROR TRANSFER FAILED Le serveur utilisé ne dispose pas du package
ABORT TRANSFER FAILED Le transfert du package a échoué

15. Vérifier Syncthing en cas de problème de synchronisation

Le document d'exploitation Medulla documente un cas dans lequel Syncthing affiche une erreur liée à la taille du buffer UDP :

failed to sufficiently increase receive buffer size
(was: 208 kiB, wanted: 2048 kiB, got: 416 kiB)

Dans ce cas précis, il recommande d'augmenter les tailles maximales des buffers de lecture et d'écriture :

sysctl -w net.core.rmem_max=2500000
sysctl -w net.core.wmem_max=2500000

Attention :
Ces commandes correspondent à un problème Syncthing précis, identifiable par le message d'erreur ci-dessus. Elles ne doivent pas être appliquées systématiquement à tout problème de synchronisation.

16. Déterminer si le problème vient du relais ou de la machine

Avant d'intervenir sur le relais, déterminez l'étendue du problème.

Constat Orientation du diagnostic
Une seule machine est affectée Vérifier la machine et son groupdeploy
Plusieurs machines du même relais sont affectées Vérifier le relais
Toutes les machines d'un subnet sont mal affectées Vérifier la règle d'attribution
Les machines communiquent mais certains packages sont absents Vérifier la disponibilité et la synchronisation des packages
Le relais est inaccessible Vérifier le serveur et les flux réseau

17. Procédure de diagnostic rapide

Lorsqu'un serveur relais Medulla semble rencontrer un problème, effectuez les contrôles suivants dans cet ordre :

  1. identifier les machines et les fonctions impactées ;
  2. relever le statut exact du déploiement s'il existe ;
  3. tester l'accessibilité du relais avec ping et SSH ;
  4. vérifier son dernier état dans uptime_machine ;
  5. vérifier sa présence et son état enabled dans relayserver ;
  6. vérifier le champ groupdeploy des machines concernées ;
  7. vérifier que le JID de groupdeploy correspond à un relais existant ;
  8. si l'affectation semble incorrecte, contrôler la règle d'attribution ;
  9. si seuls les packages sont affectés, vérifier leur disponibilité et leur synchronisation ;
  10. consulter les logs Syncthing si une erreur de synchronisation est suspectée.

18. Tableau de diagnostic rapide

Symptôme Cause possible Premier contrôle
ABORT RELAY DOWN Relais éteint ou supprimé ping, SSH et uptime_machine
ABORT ALTERNATIVE RELAYS DOWN Aucun relais alternatif disponible Contrôler les différents relais
ABORT INFO RELAY MISSING Relais absent ou groupdeploy vide Contrôler groupdeploy
Relais connu mais plus utilisé Ancienne entrée toujours activée Contrôler relayserver.enabled
Machine affectée au mauvais relais Règle d'attribution incorrecte Tester le subnet avec la règle REGEXP
Relais sans aucune machine Relais inutilisé ou de secours Requête sur groupdeploy
Package absent sur le relais Problème de distribution ou synchronisation Vérifier la disponibilité du package
Erreur de buffer Syncthing Buffer UDP insuffisant Rechercher le message exact dans les logs

19. Informations à collecter si le problème persiste

Avant de poursuivre le diagnostic ou d'ouvrir un ticket support, collectez :

  • le hostname du relais ;
  • son adresse IP ;
  • le résultat du test d'accessibilité ;
  • son dernier état dans uptime_machine ;
  • son entrée dans relayserver ;
  • la valeur de enabled ;
  • le hostname d'une machine affectée ;
  • la valeur groupdeploy de cette machine ;
  • le statut exact du déploiement ;
  • le message complet de l'audit ;
  • si le problème concerne les packages, le package et le relais concernés ;
  • les éventuelles erreurs Syncthing observées.

Recommandation :
Pour diagnostiquer un relais Medulla, commencez par distinguer trois niveaux : le relais est-il accessible ?, la machine est-elle correctement associée à ce relais ? et le relais dispose-t-il des ressources nécessaires au déploiement ? Cette approche permet de distinguer rapidement une panne du serveur relais d'un problème d'affectation ou de synchronisation des packages.

Back to top