Chaque location correspond à un nœud physique Apple Silicon dédié. En cas de problème de connexion, vérifiez d’abord l’état dans la console, puis le réseau local, l’authentification, les services système et les processus, au lieu de réinstaller la chaîne d’outils sans informations suffisantes.
Ne copiez pas l’adresse ni les identifiants depuis une conversation ou un ancien document. L’état du nœud, l’adresse de connexion, les informations du compte et les contrôles d’accès sont ceux renvoyés par la commande actuelle dans la console.
Vérifiez d’abord que le nœud physique associé à la commande est prêt à accepter les connexions. Si l’état est encore mis à jour, conservez l’identifiant de commande et attendez la prochaine indication de la console ; ne créez pas de commandes en double.
Vérifiez caractère par caractère l’adresse de l’hôte et le port, en vous assurant de ne pas avoir copié d’espace, de symbole pleine chasse ou d’informations d’un ancien nœud. Les utilisateurs d’un réseau d’entreprise doivent aussi confirmer que la politique de sortie autorise le port cible.
Utilisez les informations de compte attribuées à la commande et limitez les droits de la clé privée à la lecture par l’utilisateur actuel. Les mots de passe, clés privées et certificats de signature ne doivent pas figurer dans le corps d’un e-mail ordinaire ni dans un dépôt public.
Pour les commandes, la synchronisation du code et les tâches automatisées, privilégiez SSH ; pour accéder à l’interface graphique de macOS, utilisez le mode de connexion à distance fourni avec la commande.
Les erreurs SSH surviennent à différentes étapes. Un délai d’attente indique généralement un problème de chemin réseau ; une modification d’empreinte d’hôte exige de vérifier d’abord l’identité du nœud ; en cas d’échec d’authentification, contrôlez le nom d’utilisateur, le format de la clé et les droits du fichier.
Conservez la clé privée dans un répertoire contrôlé, hors du dépôt du projet. Si ses droits sont trop larges, le client SSH refusera d’utiliser le fichier.
chmod 600 ~/.ssh/mangovm_node
ssh -i ~/.ssh/mangovm_node -p <PORT> <USER>@<HOST>Comparez l’empreinte affichée lors de la première connexion avec celle fournie dans la console. Si vous ne pouvez pas la confirmer, interrompez la connexion et envoyez un ticket ; n’ignorez pas l’avertissement.
Les builds, archivages et installations de dépendances doivent être exécutés par un Runner, launchd ou un outil fiable de gestion de session. Ne laissez pas une tâche critique dépendre d’une seule session SSH sur votre ordinateur portable.
Vérifiez successivement le nom d’utilisateur, le chemin de la clé privée, ses droits et la correspondance de la clé avec le nœud actuel. Si le réseau est établi mais l’authentification échoue, il n’est pas nécessaire de redémarrer d’abord le nœud.
Envoyer un ticket avec le résumé d’authentificationTestez d’abord depuis un autre réseau fiable, puis notez le port cible, la sortie Internet publique du client, ainsi que les heures de début et de fin. Un délai d’attente n’est pas lié au contenu de la clé ; ne changez pas sans cesse de clé pour masquer un problème réseau.
Poursuivre dans l’arbre de diagnosticUn nœud physique fixe convient au maintien de la chaîne d’outils et du cache du projet. La stabilité repose sur une limite de concurrence claire, des répertoires de travail isolés, des journaux traçables et le nettoyage en fin de tâche, pas sur l’empilement de processus en arrière-plan.
Créez un Runner distinct pour chaque projet ou organisation et indiquez clairement dans ses étiquettes la puce, la chaîne d’outils et l’usage. Utilisez le jeton d’enregistrement uniquement dans un environnement contrôlé, puis supprimez-le des commandes temporaires et des journaux.
Les gros builds Xcode, les tests sur simulateur et les archivages peuvent mobiliser simultanément le processeur, la mémoire et le disque. Commencez avec une seule tâche, observez les pics, puis ajustez progressivement selon les journaux réels.
Les certificats de signature, clés et jetons d’accès doivent être isolés dans des variables contrôlées ou par les droits du système, sans être écrits dans le dépôt, les artefacts de build ou des journaux téléchargeables. Supprimez les fichiers temporaires à la fin de la tâche.
Notez la version soumise, la version de Xcode, le SDK, le fichier de verrouillage des dépendances, l’heure de début, le code de sortie et les erreurs clés. Dans un ticket, joignez uniquement des extraits expurgés et l’identifiant de la tâche.
Les nœuds MangoVM fonctionnent normalement 365 jours par an. Vous choisissez d’effectuer les mises à niveau de macOS et des outils de développement pendant un creux d’activité ; avant toute modification, sauvegardez les données, vérifiez la compatibilité et préparez les éléments de retour arrière.
Exportez au même instant les projets, fichiers de verrouillage des dépendances, configurations de build, journaux clés et données locales à conserver, puis notez l’étendue de la sauvegarde et le résultat de la vérification. La sauvegarde doit être séparée du disque local du nœud.
Vérifiez un à un la version cible de macOS, Xcode, le SDK, le gestionnaire de paquets, le Runner et les scripts du projet. Validez d’abord compilation, tests, archivage et préparation de l’envoi sur des tâches non critiques.
Empêchez les nouveaux builds d’entrer dans la file et vérifiez qu’aucun archivage, nettoyage du cache ou mise à jour de dépendances n’écrit sur le disque. Notez l’heure de début, l’exécutant et la version avant mise à niveau.
Si un projet essentiel ne compile plus, si le Runner ne peut pas s’enregistrer ou si une dépendance centrale est incompatible, cessez toute modification, conservez les journaux et restaurez les données et la chaîne d’outils selon les étapes prévues.
| Élément contrôlé | À relever avant la mise à niveau | Validation après la mise à niveau | À conserver en cas d’anomalie |
|---|---|---|---|
| Xcode et SDK | Version actuelle, cible du projet, chemin des outils en ligne de commande | Compilation, tests unitaires, archivage | Sortie de version et premier journal d’échec |
| Gestion des dépendances | Fichier de verrouillage, paramètres de miroir, portée du cache | Restaurer les dépendances dans un répertoire vierge | Fichier de verrouillage et extrait de l’erreur de résolution |
| Service Runner | Étiquettes, concurrence, répertoire de travail, mode de démarrage | Revenir automatiquement en ligne et prendre des tâches après redémarrage | État du service et code de sortie de la tâche |
| Données du projet | Étendue de la sauvegarde, emplacement d’export, résultat de vérification | Lecture par échantillon et test de restauration | Chemins manquants et dernière version fonctionnelle |
En cas de problème de stockage supplémentaire ou d’interconnexion Thunderbolt 5, vérifiez d’abord les options de la commande, puis la détection par le système, le chemin de montage, les droits des répertoires et la configuration de la tâche. Les prix et périodes sont ceux indiqués officiellement sur la page des offres.
Vérifiez que la commande comprend l’option souhaitée, que la période de facturation correspond et que la console a renvoyé la configuration associée. Ne vous fiez pas uniquement à un ancien chemin dans le script du projet.
Vérifiez que le système détecte le volume cible et que l’utilisateur du build dispose des droits de lecture et d’écriture nécessaires sur le répertoire de travail. N’ouvrez pas des droits excessifs sur tout le disque pour contourner le problème d’un seul répertoire.
Vérifiez chaque option interconnectée, le câblage et l’affectation des tâches. Validez d’abord les lectures-écritures ou la coopération entre nœuds avec une seule tâche reproductible, puis relancez la file groupée.
La page des offres indique les tarifs à la journée, à la semaine, au mois et au trimestre pour +1TB SSD, +2TB SSD et l’interconnexion Thunderbolt 5. Pour une question de facturation, fournissez aussi l’identifiant de commande et la période choisie.
Sauter une couche préalable mélange les symptômes. Suivez l’ordre ci-dessous et notez à chaque étape l’heure, le résultat et les modifications ; ne passez à la suivante qu’après validation de la précédente.
Vérifiez l’état du nœud, l’identifiant de commande, la région et l’exhaustivité des informations de connexion. Si les informations sont encore mises à jour, interrompez les tentatives d’authentification locales et consignez l’état actuel.
Effectuez un nouveau test depuis un autre réseau fiable afin d’écarter les différences de chemin dues à la sortie d’entreprise, au pare-feu, au proxy ou au VPN local. Notez le réseau testé et l’heure.
Vérifiez le nom d’utilisateur, le chemin de la clé, les droits du fichier et l’empreinte de l’hôte. Ne réutilisez pas directement les entrées known_hosts d’un ancien nœud ni les variables d’automatisation pour une nouvelle commande.
Vérifiez SSH, le Runner, l’agent de build et les services requis par le projet. Notez l’état des services, le dernier code de sortie et la dernière modification de configuration ; ne redémarrez pas en boucle sans journal.
Vérifiez la file de concurrence, l’espace disque, les droits du répertoire de travail, le verrouillage des dépendances et le délai d’expiration. Consignez séparément la première étape échouée et les erreurs en cascade.
Plus les informations correspondent à la couche en cause, plus l’équipe d’assistance peut reproduire le problème facilement. Tous les canaux n’acceptent que les informations nécessaires ; demandez d’abord au support comment transmettre les éléments sensibles en toute sécurité.
Indiquez la tâche visée, le niveau de concurrence, la région préférée, la durée prévue et les besoins de stockage. Pour une commande existante, fournissez son identifiant, sans envoyer d’identifiants de connexion.
Fournissez l’identifiant de commande, la région, le mode de connexion, l’heure, le réseau client, le résumé de l’erreur et les résultats des cinq premiers niveaux de l’arbre de diagnostic. N’écrivez pas seulement « impossible de se connecter ».
Arrêtez les tâches suspectes, révoquez les accès temporaires potentiellement exposés et conservez les journaux et la chronologie. Indiquez l’identifiant de commande, le mode de détection, l’étendue de l’impact et les mesures prises ; n’envoyez pas de clé encore utilisable.
Besoin d’un nouveau nœud ? Lancez directement la commande. Si une commande existante présente un problème, envoyez depuis la console un ticket contenant les étapes de reproduction et des journaux expurgés.