Diagnostiquez le problème, relancez vos builds

Une fois le paiement confirmé, connectez-vous à la console, puis ouvrez la commande concernée et les détails de son nœud pour consulter l’adresse IP, le nom d’utilisateur et le mot de passe initial. Avant de vous connecter, vérifiez que le modèle, le nœud et la durée correspondent à votre commande. L’avancement de la livraison affiché dans la console fait foi.

1. 01Vérifier la commande

   Notez le numéro de commande, le modèle et l’identifiant du nœud pour éviter d’utiliser d’anciens identifiants appartenant à un autre nœud.

2. 02Récupérer les identifiants

   Copiez l’adresse IP et le nom d’utilisateur en entier, sans espace ajouté. Ne collez pas le mot de passe initial dans un journal public.

3. 03Changer le mot de passe

   Après votre première connexion, modifiez le mot de passe de l’utilisateur actuel et enregistrez-le dans votre gestionnaire de mots de passe.

ssh -p 22 USER@NODE_IP
passwd

Remplacez USER et NODE_IP par les valeurs affichées dans la console. Si le port indiqué dans les détails est différent, utilisez celui-ci. Lors de la saisie d’un mot de passe en SSH, les caractères ne s’affichent généralement pas : c’est normal.

Distinguez d’abord un « paiement initié » d’un « paiement confirmé par la plateforme ». La page de confirmation d’un paiement par carte ou la preuve d’envoi d’un transfert on-chain ne remplacent pas l’état de paiement de la commande. Actualisez la commande concernée et vérifiez le montant ainsi que le statut de la transaction. Ne payez pas une deuxième fois simplement parce que la page n’a pas encore été mise à jour.

Si le paiement affiché ne correspond pas au statut de la commande, ouvrez un ticket depuis la console et indiquez le numéro de commande, le moyen de paiement, le montant, la date et le fuseau horaire. Pour un paiement USDT-TRC20, joignez aussi le hash de transaction. Pour une carte, fournissez les références figurant sur le reçu, sans communiquer le numéro complet de la carte, le cryptogramme ni un code reçu par SMS.

Arm Line M4 comprend un M4 / 16 Go / 256 Go ; Arm Grid M4 Pro, un M4 Pro / 64 Go / 2 To. Les deux offres sont disponibles sur cinq nœuds : Singapour, Tokyo, Séoul, Hong Kong et côte est des États-Unis. La disponibilité réelle est celle indiquée en temps réel dans la console.

Pour les usages interactifs, tenez compte du réseau entre votre équipe et le nœud. Pour les builds sans supervision, prenez aussi en compte les transferts de code, de dépendances et d’artefacts. Si la commande ne correspond pas à vos attentes, faites-la vérifier dans un ticket avant de transférer votre projet et vos éléments de signature.

Fermez d’abord les sessions à distance en double, puis reconnectez-vous. Vérifiez que le client cible le bon nœud et que macOS n’est pas verrouillé ou sur l’écran de changement d’utilisateur. Si SSH fonctionne toujours, sauvegardez les journaux de build ; ne forcez pas le redémarrage d’un nœud en plein archivage.

Si vous pouvez accéder à l’interface graphique, vérifiez le partage d’écran et les utilisateurs autorisés dans « Réglages Système → Général → Partage ». Leur emplacement peut varier selon la version de macOS. Vous pouvez consulter l’utilisateur de la console via SSH pour vérifier si une session graphique est ouverte :

stat -f '%Su' /dev/console

Si l’écran reste noir, indiquez dans le ticket si SSH est accessible, ce que vous faisiez juste avant le problème ainsi que le nom et la version du client. Joignez une capture d’écran sans mot de passe. N’arrêtez pas des processus système à répétition pour tenter de résoudre le problème.

Dans le client VNC, choisissez d’abord le mode « Adapter à la fenêtre » afin de distinguer le zoom du client de la résolution réelle à distance. Vérifiez les options d’affichage distantes dans « Réglages Système → Moniteurs ». Commencez par 1 920 × 1 080, puis ajustez selon l’écran du client et la qualité du réseau.

Pour une connexion à longue distance, réduisez d’abord la résolution et la profondeur des couleurs, puis augmentez le niveau de compression. Vérifiez que la saisie de texte et les menus restent réactifs avant d’améliorer la qualité d’image. Les builds ne dépendent pas de la qualité du bureau à distance : gardez une résolution élevée uniquement si elle vous est utile pour consulter les journaux.

Un « délai d’attente » signifie généralement que le réseau ou le port ne répond pas. Un « refus de connexion » indique qu’une réponse de refus a été reçue : vérifiez le port et le service. En cas d’« échec d’authentification », vérifiez le nom d’utilisateur, le mot de passe ou la clé. Commencez par ces commandes dans votre terminal local, puis joignez au ticket les extraits de journal nécessaires :

nc -vz NODE_IP 22
ssh -vv -o ConnectTimeout=10 -p 22 USER@NODE_IP

Si le réseau de votre entreprise bloque les connexions sortantes, essayez depuis un autre réseau et notez les résultats des deux tests. Ne conservez que les lignes d’erreur dans les journaux et masquez les données sensibles, comme l’adresse IP publique, le nom d’utilisateur et le chemin de la clé privée. N’envoyez pas votre clé privée à l’équipe d’assistance.

Après une réinstallation complète, l’empreinte de l’hôte peut changer. Vérifiez l’identité du nœud dans la console avant de poursuivre ; n’ignorez pas l’avertissement de clé d’hôte sans avoir confirmé son identité.

Sur le Mac distant, vérifiez la source de saisie dans « Réglages Système → Clavier → Saisie de texte », puis les correspondances de Commande, Option et Contrôle dans « Touches de modification ». Les touches de modification ne sont pas au même endroit sur un clavier Windows et un clavier Mac. Testez les symboles dans un éditeur de texte avant de saisir des commandes dans le terminal.

Si le problème ne se produit que dans le client distant, vérifiez sa disposition de clavier et le transfert des raccourcis. Si le presse-papiers ne se synchronise pas, reconnectez-vous et vérifiez les options de partage du client. N’utilisez pas un service de presse-papiers public pour transférer des mots de passe ou des éléments de signature.

Commencez par vérifier le répertoire Developer actif et la version d’Xcode. Le fait qu’une version soit ouverte dans l’interface graphique ne signifie pas que la ligne de commande utilise la même. Un changement global affecte les tâches exécutées sur le même nœud ; pour un pipeline partagé, mieux vaut définir DEVELOPER_DIR dans chaque tâche.

xcode-select -p
xcodebuild -version
DEVELOPER_DIR=/Applications/Xcode.app/Contents/Developer \
  xcodebuild -version

Le chemin doit pointer vers une version d’Xcode réellement présente sur le nœud. Si vous devez changer la version par défaut, mettez d’abord en pause les tâches qui dépendent de la chaîne d’outils actuelle, puis exécutez sudo xcode-select --switch /Applications/Xcode.app/Contents/Developer. Effectuez la première vérification des composants et des conditions de licence dans une session interactive.

Vérifiez l’utilisateur d’exécution du runner et le trousseau qui contient le certificat. Une session ouverte dans l’interface graphique n’est pas forcément disponible pour un service en arrière-plan. Après un redémarrage, il peut aussi être nécessaire de déverrouiller un trousseau dédié au build, selon la configuration du pipeline. Ces commandes permettent de consulter les identités de signature et de déverrouiller le trousseau dans une session interactive :

security find-identity -v -p codesigning
security unlock-keychain "$HOME/Library/Keychains/build.keychain-db"

Le trousseau de build utilisé en exemple doit exister au préalable. Pour les tâches sans supervision, lisez les identifiants nécessaires depuis les variables secrètes de la CI, désactivez l’écho des commandes et limitez l’accès aux certificats. Pour le diagnostic, fournissez uniquement le code d’erreur et des journaux expurgés. N’envoyez ni mot de passe de trousseau, ni clé privée, ni mot de passe d’export de certificat.

Commencez par conserver la méthode de signature déjà validée pour le projet. La signature automatique convient aux processus disposant d’une autorisation d’automatisation contrôlée ; un profil manuel convient aux pipelines de publication qui doivent fixer le certificat, le profil et les options d’export. Ne changez pas simultanément de méthode de signature et de version d’Xcode pendant un même diagnostic.

Avec une configuration manuelle, vérifiez un par un le Bundle Identifier, l’identifiant de l’équipe, la date d’expiration du certificat, le type de profil et la méthode d’export. Dans les projets à plusieurs targets, vérifiez aussi les identifiants et les autorisations des extensions. Distinguez les échecs de compilation des échecs d’export ; dans le ticket, indiquez l’étape en échec, le message d’erreur exact et une configuration d’export expurgée.

Vérifiez d’abord sur la plateforme de gestion du code que le runner est toujours enregistré, puis contrôlez l’état du service sur le nœud, l’association au dépôt et les labels des tâches. Exécutez les commandes GitHub Actions ci-dessous depuis le répertoire d’installation du runner. Pour GitLab Runner, le programme correspondant doit être installé :

./svc.sh status
gitlab-runner status
launchctl list | grep -i runner

Pour un service géré par launchd, vérifiez l’utilisateur d’exécution, le répertoire de travail et le chemin des journaux dans sa définition. Un lancement au démarrage et un lancement à la connexion de l’utilisateur sont deux choses différentes : après la configuration, testez le service sans terminal interactif. Ne collez pas de jeton d’enregistrement du runner dans un ticket.

Commencez par afficher dans la tâche en échec les informations d’environnement non sensibles, puis vérifiez l’utilisateur réel, le répertoire courant, le PATH et la version d’Xcode. Un service en arrière-plan ne charge généralement pas toute la configuration du shell interactif.

whoami
pwd
printf '%s\n' "$PATH"
xcodebuild -version

Définissez explicitement les chemins des dépendances dans l’environnement de la tâche. Pour les tâches concurrentes, utilisez des chemins distincts pour l’espace de travail, DerivedData, les archives et les fichiers temporaires. Effectuez d’abord un build propre avec une seule tâche, puis augmentez progressivement la concurrence. Ne laissez pas deux publications modifier en même temps le même répertoire d’export ou les mêmes ressources de signature.

Sélectionnez impérativement le réseau TRC20. Vérifiez attentivement l’adresse de réception, le montant dû et les instructions affichés pour la commande en cours. Ne réutilisez pas une adresse d’une autre commande ou d’une ancienne capture d’écran. Avant d’envoyer le transfert, vérifiez que le bon réseau est sélectionné dans votre portefeuille.

La confirmation on-chain prend généralement quelques minutes ; patientez un peu pour suivre l’état de la transaction. Le délai dépend de la congestion du réseau, de la diffusion par le portefeuille et du nombre de confirmations exigé par la passerelle de paiement : aucun délai fixe n’est garanti. Fiez-vous au résultat affiché dans la commande. L’envoi du transfert ne signifie pas que la plateforme en a confirmé la réception.

Si la transaction est confirmée, mais que la commande n’a pas été mise à jour, envoyez le numéro de commande, le hash de transaction, le montant transféré, la date et le fuseau horaire. Ne faites pas un deuxième transfert et ne communiquez ni phrase de récupération ni clé privée de portefeuille dans un ticket.

Les paiements Visa / Mastercard / Amex sont traités par Stripe. Après le paiement, revenez dans la console pour vérifier le statut de la facture et le montant en USD. Si la banque affiche une transaction, mais que le statut de la facture ne correspond pas, conservez le reçu et ouvrez un ticket. Ne relancez pas plusieurs paiements à la suite.

Indiquez le numéro de commande, la date et le fuseau horaire du paiement, le montant, le message d’échec ou la référence de paiement. Sur les captures d’écran, masquez le numéro complet de la carte, le cryptogramme et toute donnée personnelle sensible. L’équipe d’assistance n’a pas besoin de votre code reçu par SMS.

Quatre durées de location sont proposées : jour, semaine, mois et trimestre. Consultez la commande et la facture correspondantes dans la console pour connaître la date de début, la date de fin, l’état du renouvellement et celui de la commande. Ne calculez pas vous-même la date de fin du service à partir de l’heure à laquelle vous avez initié un transfert.

Avant l’échéance, vérifiez l’état du renouvellement et la facture à régler dans la commande. Ne supposez pas que le service sera prolongé sans paiement. Mettre temporairement un runner hors service ou couper la connexion SSH ne met pas fin à la location. Pour modifier la configuration, confirmez d’abord la marche à suivre dans un ticket, puis planifiez la migration du projet et la mise en pause des builds.

À la fin de la location, les données du nœud sont effacées. Avant la fin du service, transférez le code source, les artefacts archivés, les journaux nécessaires et vos sauvegardes de configuration, puis vérifiez que les sauvegardes peuvent être restaurées. Le disque du nœud ne doit pas être votre seule copie.

Désenregistrez également les runners, révoquez les jetons d’automatisation utilisés sur le nœud et traitez les éléments de signature conformément à votre politique de sécurité. Si vous passez à un autre nœud, vérifiez d’abord le nouveau nœud avant d’y transférer les tâches de publication.