Cette page regroupe les procédures de diagnostic des connexions, builds, runners, réseaux et stockages sur les nœuds physiques Apple Silicon dédiés. Chaque étape précise quoi vérifier, quelle commande exécuter et quel résultat permet de déterminer la suite.
Si vous disposez déjà d’un nœud, notez d’abord son identifiant et la période concernée. Si vous n’avez pas encore commandé, consultez les trois configurations disponibles et les quatre nœuds proposés.
Ne modifiez pas la configuration sur plusieurs niveaux à la fois. Choisissez la catégorie la plus proche du symptôme, effectuez les vérifications de base, puis passez au niveau suivant avec les résultats obtenus.
Commencez par l’adresse, le port, les autorisations de clé, l’empreinte de l’hôte et la validité des identifiants. Si SSH fonctionne mais que la session graphique présente un problème, vérifiez ensuite la résolution, le verrouillage et la reprise de session.
Commencez par figer la version de Xcode et conserver les journaux d’origine, puis vérifiez l’identité de signature, le profil de provisioning, les autorisations du Keychain, DerivedData et le répertoire de travail du runner.
Vérifiez dans le portail le numéro de commande, la période de location, l’identifiant du nœud et l’état du paiement. Ne transmettez ni le contenu des clés ni des identifiants de paiement complets dans un ticket.
Notez l’espace disque disponible, le nom du volume, la qualité du réseau et l’arborescence des périphériques Thunderbolt. Ne formatez pas un disque et ne recréez pas un volume sans sauvegarde.
Un échec de connexion ne signifie pas forcément que le nœud est hors ligne. Distinguez d’abord une adresse incorrecte, un port inaccessible, des autorisations locales de clé non conformes, une modification de l’empreinte de l’hôte et un refus d’authentification du serveur.
$ chmod 600 ~/.ssh/orbvps_node
$ ssh-keygen -F node-address
$ nc -vz node-address 22
$ ssh -vvv -p 22 \
-i ~/.ssh/orbvps_node \
node-user@node-addressVérifiez que le nom d’utilisateur et la clé privée correspondent au nœud actuel, et contrôlez qu’aucun autre IdentityFile de la configuration SSH locale ne prend le dessus.
Vérifiez l’adresse et le port affichés dans le portail, désactivez temporairement les règles de proxy locales pour retester, puis notez l’heure et le réseau utilisé.
Conservez toute la sortie verbose et ne supprimez pas plusieurs fois les entrées d’hôte ; vérifiez d’abord que le port correspond aux informations de livraison du nœud.
N’ignorez pas directement l’avertissement. Comparez d’abord l’empreinte affichée avec les informations de livraison du portail, puis mettez à jour l’enregistrement local après confirmation du nœud.
Relisez l’adresse, le port et le nom d’utilisateur dans le portail ; n’utilisez pas une adresse supposée à partir de l’historique d’un ancien terminal.
La clé privée doit idéalement être lisible et modifiable par l’utilisateur actuel ; la configuration SSH et les répertoires parents ne doivent pas être modifiables par des utilisateurs non concernés.
Réessayez une fois en mode verbose, conservez toute la sortie depuis le début de la connexion jusqu’à l’échec et masquez l’adresse.
La session graphique et SSH reposent sur deux chaînes distinctes. Le bon fonctionnement de SSH ne garantit pas celui de la session graphique ; consignez donc séparément les symptômes.
Utilisez uniquement les identifiants de session graphique fournis pour le nœud actuel. Après une rotation, supprimez l’ancien mot de passe enregistré par le client afin d’éviter les nouvelles tentatives automatiques.
En cas d’écran noir ou d’image figée, commencez avec une résolution réduite et un seul écran. Augmentez ensuite progressivement la résolution pour déterminer si le problème vient des paramètres d’affichage.
Si l’écran de verrouillage s’affiche mais que vous ne pouvez pas continuer, vérifiez d’abord la saisie et le focus du clavier, puis contrôlez la charge système et l’espace disque disponible via SSH.
Fermez d’abord volontairement la connexion du client, attendez la libération de la session, puis reconnectez-vous. Ne créez pas rapidement plusieurs sessions graphiques parallèles, afin d’éviter toute confusion entre les bureaux utilisés.
Indiquez si SSH fonctionne, l’étape à laquelle le client graphique s’arrête, la résolution utilisée, le message d’erreur exact du client et la période de la dernière connexion réussie. Ne transmettez pas le mot de passe d’accès complet.
Vérifiez d’abord le chemin et la version de Xcode réellement utilisés, puis contrôlez les identités de signature disponibles, les profils de provisioning, l’accès au Keychain et le cache du projet. Ne mettez pas à jour les dépendances et ne remplacez pas les éléments de signature lors du même diagnostic.
xcodebuild -version le résultat complet.xcode-select -p pour vérifier le répertoire Developer actuel..xcresultau lieu de transmettre uniquement les dernières lignes du terminal.$ xcode-select -p
$ xcodebuild -version
$ security find-identity \
-v -p codesigning
$ profiles show \
-type provisioning
$ xcodebuild \
-workspace App.xcworkspace \
-scheme App \
-configuration Release \
-resultBundlePath Build.xcresult \
buildConservez la commande, le scheme, la configuration, la cible en échec, la première erreur et son contexte. Supprimez les identifiants du dépôt, les jetons et les données métier avant transmission.
Un runner self-hosted affiché comme en ligne ne garantit pas que l’environnement de tâche est complet. Vérifiez le processus du runner, les autorisations du répertoire de travail, l’utilisation du cache, les tâches concurrentes et la reprise automatique après redémarrage.
Vérifiez que le service du runner s’exécute toujours avec l’utilisateur attendu et que ses paramètres de démarrage pointent vers la bonne configuration. Si le processus s’arrête à répétition, conservez d’abord le code de sortie et les journaux récents.
ps aux | grep -i runner
Vérifiez le propriétaire du répertoire, l’espace disponible et les fichiers de verrouillage d’anciennes tâches. Ne supprimez pas directement un répertoire encore utilisé par une tâche en cours.
df -h && du -sh ./work
Distinguez le cache des dépendances, DerivedData et les artefacts de build. Identifiez d’abord la clé de cache anormale, puis nettoyez uniquement le projet concerné afin de préserver les éléments réutilisables.
du -sh ~/Library/Developer/Xcode/DerivedData
Vérifiez si plusieurs tâches utilisent simultanément le même Keychain, simulateur ou répertoire de travail. Après un redémarrage, exécutez d’abord une tâche de test contrôlée, puis réactivez la file normale.
uptime && sysctl -n hw.memsize
Si la tâche de test réussit mais que les tâches concurrentes échouent, indiquez également le nombre de tâches simultanées, leurs étiquettes et la liste des ressources partagées.
Une baisse du débit, un build ralenti et la disparition d’un volume externe peuvent produire des symptômes similaires. Collectez d’abord les diagnostics intégrés au système, puis déterminez si le problème concerne le réseau, le système de fichiers ou le chemin du périphérique externe.
Utilisez l’outil système de mesure de la qualité du réseau pour enregistrer les capacités montantes et descendantes ainsi que la réactivité, et notez la période du test. Les résultats interrégionaux dépendent de l’opérateur local et du chemin réseau.
networkQuality -v
route -n get default
ifconfigVérifiez d’abord l’espace disponible sur les volumes système et de données, puis localisez les répertoires de travail les plus volumineux. En cas d’échec de build, contrôlez particulièrement les répertoires temporaires et DerivedData.
df -h
diskutil list
du -sh ~/Library/Developer/*Vérifiez séparément la liste des disques et l’arborescence des périphériques Thunderbolt. Si le périphérique est visible mais que le volume n’est pas monté, collectez d’abord son état ; ne l’effacez pas et ne le repartitionnez pas immédiatement.
diskutil list external
system_profiler SPThunderboltDataType
diskutil info /Volumes/VolumeNameLes nœuds OrbVPS fonctionnent normalement 365 jours par an. Les mises à niveau système, changements de chaîne d’outils et opérations nécessitant un redémarrage sont planifiés par l’utilisateur selon sa charge de travail ; en cas de modification urgente de l’infrastructure, les informations pertinentes seront consignées dans le portail.
Notez les versions actuelles de macOS, Xcode et du runner, les dépendances essentielles et les journaux de build permettant un retour arrière ; ne remplacez pas la chaîne d’outils sans base de référence.
Sauvegardez le dépôt, les éléments de signature, la configuration du runner, la stratégie de cache et les artefacts de build nécessaires, puis vérifiez depuis un emplacement distinct que la sauvegarde est lisible.
Mettez en pause les nouvelles tâches, attendez la fin des tâches en cours et enregistrez les journaux avant de redémarrer. Ne modifiez pas simultanément le réseau, la signature et la configuration de build pendant le redémarrage.
Vérifiez successivement SSH, le bureau graphique, le montage des disques, la version de Xcode et une tâche de build contrôlée, puis rétablissez la file de tâches concurrentes.
Indiquez l’identifiant du nœud, la période concernée, les tâches affectées, les commandes exécutées, la sortie d’origine et les captures d’écran expurgées. Si vous avez déjà une commande, ouvrez un ticket dans le portail ; avant achat, envoyez les questions de configuration ou de région depuis la page de contact à support@orbvps.com.