ASSISTANCE TECHNIQUE

Conservez d’abord les preuves, puis réduisez le périmètre de la panne de votre Mac dans le cloud

Ce guide technique suit un ordre d’exécution précis. Vérifiez d’abord l’appareil et le réseau, puis Xcode, la signature et l’environnement CI, avant de traiter le stockage, les mises à niveau et la récupération.

Louer un Mac dans le cloud Accéder à la console
6 catégories Points d’entrée pour les problèmes techniques
5 Nœuds disponibles
365 jours Nœuds opérationnels
Ticket d’assistance EXÉCUTION / ASSISTANCE
Vérifiez dans l’ordre des dépendances

Connexion → Environnement → Build → Données

PRÊT
01 / Appareil
Identifiant de l’appareil, nœud, empreinte d’hôte
02 / Réseau
Accès local, routage, port et latence
03 / Chaîne d’outils
macOS, Xcode, certificats et dépendances
04 / Tâche
Commande de reproduction, journaux, code de sortie et horodatage
Avant d’envoyer un ticket Anonymisez les journaux et notez les étapes déjà effectuées
INDEX DU GUIDE

Commencez par le point de blocage actuel, sans devoir tout lire depuis le début

Six points d’entrée traitent respectivement la vérification d’identité, les changements système, les outils de développement, l’automatisation, le routage réseau et les informations de commande. Chacun précise quoi vérifier, quoi conserver et quand ouvrir un ticket.

01 / CONNEXION

Première connexion

Récupérez les informations de connexion, vérifiez l’empreinte d’hôte, établissez une session SSH et écartez les problèmes réseau de base avant d’activer l’interface graphique.

Suivre l’ordre de connexion 02 / SYSTÈME

Gestion de macOS

Avant toute modification système, sauvegardez les données, les versions et les éléments de récupération. Validez ensuite la chaîne d’outils avant de lancer les tâches de longue durée.

Voir les mises à niveau et la récupération 03 / CHAÎNE D’OUTILS

Environnement de développement

Identifiez les échecs Xcode en vérifiant successivement les certificats, les profils, les autorisations Keychain, DerivedData et les journaux de build.

Accéder au dépannage Xcode 04 / RUNNER

Intégration CI/CD

Vérifiez l’identité du runner, le répertoire de travail, les limites du cache, l’injection des clés et la procédure de retour arrière reproductible après un échec.

Voir la liste des runners 05 / RÉSEAU

Diagnostic réseau

Comparez les cinq nœuds via une connexion filaire, un échantillon fixe et la même plage horaire, en distinguant d’abord l’accès local des effets du routage international.

Voir les mesures de latence 06 / COMMANDE

Compte et commandes

Associez chaque problème à son numéro de commande et à l’identifiant de l’appareil. Ne transmettez jamais de numéro de carte complet, de clé privée ou de mot de passe dans les journaux ou les tickets.

Préparer les éléments du ticket
ORDRE DE CONNEXION

En cas d’échec, identifiez d’abord la machine cible, puis l’outil de connexion

Ne changez pas de client à répétition avant d’avoir vérifié l’adresse de l’hôte, le port et les identifiants. Suivez les quatre étapes ci-dessous dans l’ordre : chacune fournit une entrée vérifiable pour la suivante.

  1. 01

    Consulter les informations de l’appareil

    Connectez-vous à la console et vérifiez, dans la commande concernée, l’identifiant de l’appareil, le nœud sélectionné, l’adresse de l’hôte, le port SSH et les identifiants actuels. Si vous utilisez plusieurs appareils en parallèle, associez d’abord chaque numéro de commande à son identifiant d’appareil.

    À conserver Numéro de commande, identifiant de l’appareil, nœud, port
  2. 02

    Vérifier l’empreinte d’hôte

    Lors de la première connexion, comparez l’empreinte affichée par le client avec celle enregistrée dans la console. Si elle change après la réinstallation de l’appareil, vérifiez d’abord l’historique de modification, puis supprimez l’ancienne entrée locale ; n’ignorez jamais directement l’avertissement.

    ssh-keygen -R example-host
ssh -p 22 user@example-host
  3. 03

    Établir d’abord une base SSH

    Depuis une connexion filaire, testez d’abord le DNS, le port et SSH. En cas de réussite, notez l’heure de connexion, le réseau de sortie et la réponse de la ligne de commande ; en cas d’échec, conservez le message complet au lieu de ne garder que « connexion échouée ».

    À retenir Un délai d’attente indique plutôt un problème de routage ou de port ; un refus de connexion concerne plutôt le service cible ; une erreur d’authentification impose de vérifier en priorité les identifiants et les autorisations.
  4. 04

    Configurer ensuite la connexion graphique

    Une fois la base SSH stable, vérifiez l’adresse, le port, la version du client et le pare-feu local nécessaires à l’interface graphique. En cas de saccades, notez aussi la résolution, les paramètres d’encodage et la latence réseau.

    Limite Une interface graphique fonctionnelle ne garantit pas qu’un aperçu vidéo à haut débit sera équivalent à un affichage local : validez selon le chemin réseau réel.
MESURE DU RÉSEAU

Comparez la médiane des pings des cinq nœuds sur une base identique

Le tableau illustre les différences de routage entre les grandes villes et Singapour, le Japon (Tokyo), la Corée du Sud (Séoul), Hong Kong et l’ouest des États-Unis. Ces valeurs servent de référence de sélection et ne garantissent ni le débit applicatif, ni la fréquence d’image de l’interface graphique, ni la durée d’exécution des tâches.

Créneau de test Jours ouvrés, 14:00–16:00 UTC+8
Échantillon 50 mesures par nœud
Accès Réseau filaire Gigabit
Valeur statistique Médiane du temps aller-retour
Médiane indicative des pings entre trois grandes villes et cinq nœuds VMDebug, en millisecondes
Source du test Opérateur Singapour Japon (Tokyo) Corée du Sud (Séoul) Hong Kong Ouest des États-Unis
Shanghai China Telecom 71 ms 42 ms 46 ms 34 ms 141 ms
Shenzhen China Unicom 44 ms 55 ms 59 ms 18 ms 157 ms
Pékin China Mobile 91 ms 48 ms 39 ms 63 ms 138 ms
Tester d’abord le réseau local

Écartez les variations du Wi-Fi et de la sortie locale

Utilisez une connexion Ethernet directe et mettez en pause la synchronisation de gros fichiers, les visioconférences et les mises à jour système. Testez successivement la passerelle locale et l’adresse du nœud ; si les deux fluctuent, traitez d’abord l’accès local.

Examiner ensuite le routage

La médiane ne suffit pas à expliquer toute l’expérience

L’interaction à distance dépend aussi de la perte de paquets, de la gigue, de la bande passante montante et de l’encodage du client. Pour signaler un problème réseau, fournissez également l’opérateur, la ville, le créneau, la taille de l’échantillon et le résultat du traceroute.

DIAGNOSTIC XCODE

En cas d’échec de signature, ne supprimez pas d’abord l’environnement : vérifiez les cinq niveaux de dépendances

Une même erreur peut venir d’un certificat inutilisable, d’un profil incompatible, d’un accès refusé au Keychain, d’un cache pollué ou de paramètres de build différents. Enregistrez d’abord les journaux bruts, puis suivez l’ordre ci-dessous.

  1. 01

    Certificat

    Vérifiez que le certificat cible existe et n’est pas expiré, que le certificat et la clé privée correspondent et que l’utilisateur de build actuel peut le lire. Listez d’abord les identités de signature ; ne réimportez pas immédiatement tous les éléments.

    security find-identity -v -p codesigning
  2. 02

    Profil d’approvisionnement

    Vérifiez le Bundle Identifier, l’identifiant d’équipe, le type de certificat, le périmètre des appareils et les capacités déclarées. Pour un projet signé manuellement, assurez-vous que la configuration pointe réellement vers le fichier cible et non vers un ancien cache.

    CODE_SIGN_STYLE / PROVISIONING_PROFILE_SPECIFIER
  3. 03

    Autorisations Keychain

    L’utilisateur CI et l’utilisateur connecté de manière interactive peuvent utiliser des listes de recherche Keychain différentes. Vérifiez que le Keychain cible est déverrouillé, présent dans le chemin de recherche et que le processus de build peut lire la clé privée.

    security list-keychains
  4. 04

    DerivedData

    Notez d’abord le chemin actuel et la tâche en échec, puis ne supprimez que les données dérivées du projet concerné. Ne faites pas de la suppression de tous les caches la première étape : vous perdriez des éléments de comparaison utiles.

    xcodebuild -showBuildSettings
  5. 05

    Journaux de build

    Conservez la commande complète, le Scheme, la Configuration, le SDK, la version de Xcode, le code de sortie et l’emplacement du premier échec. Examinez en priorité la première erreur racine, pas la dernière ligne de synthèse.

    xcodebuild -version
RUNNER CI/CD

Traitez le runner comme une exécution reproductible, pas comme un répertoire de travail permanent

Un Mac physique dédié peut exécuter des builds en continu, mais la stabilité dépend toujours de l’identité, des répertoires, du cache, des clés et des limites de retour arrière. Chaque modification doit répondre à trois questions : qu’est-ce qui a changé, comment le valider et comment revenir en arrière ?

Liste de vérification de l’intégration du runner 5 CONTRÔLES
  1. 01

    Enregistrer l’identité du runner

    Utilisez pour chaque appareil un nom et des étiquettes de runner explicites, et consignez le périmètre d’enregistrement, l’utilisateur de service et le mode de démarrage. Évitez les noms identiques impossibles à distinguer.

  2. 02

    Isoler les répertoires de travail

    Créez un répertoire indépendant par dépôt, branche ou tâche. Interdisez aux tâches concurrentes d’écrire dans le même DerivedData, répertoire d’archives ou emplacement de sortie des dépendances.

  3. 03

    Définir les limites du cache

    Distinguez les caches reconstruisibles des artefacts à conserver. Avant tout nettoyage, notez la taille du répertoire, sa dernière utilisation et la tâche associée afin d’éviter un démarrage à froid inutile.

  4. 04

    Injecter les clés à l’exécution

    Les clés ne doivent rejoindre l’environnement du processus ou un Keychain temporaire que lorsque la tâche l’exige. Désactivez leur affichage dans les journaux, supprimez les éléments temporaires à la fin et verrouillez l’accès.

  5. 05

    Définir le retour arrière en cas d’échec

    Avant de mettre à jour le runner, Xcode ou une dépendance, conservez l’historique des versions. En cas d’échec de validation, restaurez les fichiers de configuration, la sélection de la chaîne d’outils et les index du cache au lieu d’empiler les modifications.

Répertoire de travail

Générez un chemin unique pour chaque tâche

Le chemin doit contenir au moins l’identifiant du projet, celui de la tâche et le nombre de tentatives. Le nettoyage ne doit cibler que le répertoire de la tâche en cours afin d’éviter de supprimer un build concurrent.

WORK_ROOT="$HOME/ci-work"
JOB_DIR="$WORK_ROOT/$PROJECT/$RUN_ID"
mkdir -p "$JOB_DIR"
Preuves d’échec

Archivez quatre catégories d’informations avant la fin

Conservez la version du runner, celle de la chaîne d’outils, le code de sortie complet et le premier journal de cause racine. Le taux de succès du cache et l’espace disque disponible doivent aussi figurer dans le résumé de la tâche pour faciliter les comparaisons.

  • Versions du runner et de macOS
  • Chemin et version de Xcode
  • Commande, code de sortie et journaux
  • Espace disque disponible et état du cache
STOCKAGE ET TB5

Avant de monter un stockage externe, créez une copie récupérable ; avant de connecter plusieurs appareils, clarifiez la topologie

Le stockage externe et les connexions Thunderbolt 5 en parallèle modifient le chemin des données et les limites d’autorisation. Avant tout formatage, changement de point de montage ou déconnexion, vérifiez la copie des données et l’arrêt des tâches.

Stockage externe

Vérifications avant montage

  1. Confirmer la copie des données

    Conservez au moins une copie indépendante du code important, des ressources, des artefacts de build et de la configuration. Un volume monté non vérifié ne doit pas être le seul emplacement de stockage.

  2. Identifier le disque

    Notez le nom du volume, le système de fichiers, la capacité, l’identifiant de l’appareil et le point de montage prévu. Ne vous fiez pas uniquement à l’ordre d’affichage pour identifier le disque cible.

  3. Vérifier les autorisations d’accès

    Vérifiez que l’utilisateur exécutant les builds ou les tâches multimédias dispose des droits nécessaires sur les répertoires concernés. Ne contournez pas un problème de propriété en élargissant globalement les autorisations.

  4. Effectuer une vérification de lecture-écriture

    Utilisez d’abord un fichier de test supprimable pour vérifier la création, la lecture, le renommage et la suppression, puis migrez le véritable répertoire de travail.

Thunderbolt 5

Ordre de connexion de plusieurs appareils

  1. Dessiner la topologie physique

    Indiquez chaque Mac, le sens des câbles, le stockage partagé et le rôle des tâches. Ne modifiez pas les connexions sans pouvoir identifier les appareils en amont et en aval.

  2. Uniformiser les limites d’autorisation

    Déterminez quel appareil écrit et lesquels sont en lecture seule. Attribuez aux tâches automatisées des répertoires indépendants afin d’éviter les écrasements concurrents.

  3. Valider le chemin appareil par appareil

    Après chaque ajout, effectuez un test de connexion, d’autorisation et de lecture-écriture. N’attendez pas que tout soit câblé pour commencer le diagnostic.

  4. Déconnecter dans l’ordre inverse des tâches

    Arrêtez d’abord les écritures et les builds, vérifiez que le cache est bien enregistré, puis démontez le volume et déconnectez les appareils en commençant par l’extrémité du chemin.

MISE À NIVEAU ET RÉCUPÉRATION

Une mise à niveau système doit disposer d’une machine de validation, d’une base de référence et de supports de retour arrière

Tous les nœuds restent opérationnels 365 jours par an. Les mises à niveau de macOS et de la chaîne d’outils sont planifiées par l’utilisateur selon le rythme des tâches : validez-les d’abord sur des tâches non critiques, puis déployez-les sur les runners de longue durée.

Ordre d’exécution de la mise à niveau 6 PHASES
  1. 01

    Créer un inventaire de référence

    Exportez l’état du code, les fichiers de verrouillage des dépendances, la liste Homebrew, le chemin Xcode, les noms des certificats, la liste Keychain, la configuration du runner et l’espace disque disponible.

  2. 02

    Sauvegarder les données non reconstructibles

    Déplacez la configuration privée, les éléments de signature, les artefacts de build et les données du projet vers un emplacement indépendant, puis vérifiez concrètement qu’au moins un fichier peut être restauré.

  3. 03

    Valider la compatibilité de la chaîne d’outils

    Vérifiez la compatibilité entre macOS cible, Xcode, outils en ligne de commande, gestionnaire de paquets, runner et dépendances du projet. Notez les anciennes versions à conserver.

  4. 04

    Suspendre les tâches d’écriture

    Arrêtez les files CI, le traitement des ressources et la synchronisation des données. Vérifiez qu’aucun processus ne continue d’écrire dans les répertoires de travail, le cache ou le stockage externe.

  5. 05

    Effectuer la validation minimale

    Après la mise à niveau, vérifiez successivement SSH, les disques, la version de Xcode, la lecture des certificats, la restauration des dépendances, les tests, l’archivage et le téléchargement des artefacts.

  6. 06

    Enregistrer la nouvelle base de référence

    Enregistrez la durée, les journaux, l’état du cache et l’espace disque de la première tâche réussie, puis réactivez progressivement les tâches concurrentes au lieu de libérer toute la file d’un coup.

Conditions d’arrêt

Revenez en arrière dans les cas suivants

  • Un certificat critique ou une clé privée est illisible
  • La version de Xcode requise par le projet est indisponible
  • Le stockage externe passe en lecture seule ou présente une anomalie de montage
  • La même commande de référence produit un nouvel échec reproductible

N’effectuez pas plusieurs mises à niveau successives avant d’avoir identifié la cause racine : les journaux ne permettraient plus de distinguer l’impact du système, de la chaîne d’outils et de la configuration du projet.

Éléments du ticket

Donnez à l’assistance les moyens de reproduire directement le problème

  • Numéro de commande et identifiant de l’appareil
  • Période du problème et nœud sélectionné
  • Versions de macOS, Xcode et du runner
  • Étapes minimales de reproduction et résultat attendu
  • Journaux complets anonymisés et code de sortie
  • Vérifications effectuées et résultats
Envoyer un ticket depuis la console
ACTION SUIVANTE

Les journaux sont anonymisés : transmettez le ticket à l’équipe d’assistance

Pour un problème lié à une commande existante, envoyez un ticket depuis la console en joignant l’identifiant de l’appareil, les étapes de reproduction et le contexte complet de l’erreur. Pour une question de configuration avant commande, contactez-nous via l’adresse e-mail d’assistance dédiée.

support@vmdebug.com
Envoyer un ticket depuis la console Voir les moyens de contact