SSH
Première connexion
Vérifiez les droits de la clé, l’empreinte de l’hôte, le nom d’utilisateur, le port et le réseau local afin de déterminer si l’échec survient avant ou après l’authentification.
Diagnostiquer la connexion
Connexion, build et diagnostic
Décomposez les problèmes de votre Mac dans le cloud en vérifications concrètes
Oubliez le réflexe « réessayez ». Vérifiez d’abord le point d’entrée, puis les outils, les dépendances, les éléments de signature, l’espace disque et les logs. Chaque étape indique les résultats à observer, pour les builds iOS, l’automatisation macOS et les expériences MLX sur un nœud physique dédié OakVPS.
Pour une commande existante, connectez-vous à la console et ouvrez un ticket. N’envoyez jamais de clé privée, de mot de passe de certificat de signature ou de données de paiement complètes sur une page publique.
Choisir une tâche
Identifiez d’abord l’étape où le problème survient
Six points d’entrée sont disponibles. Si le problème couvre plusieurs étapes, commencez par la première anomalie au lieu de vider tout l’environnement.
XCODE
Build Xcode
Vérifiez la chaîne d’outils, le scheme du projet, l’état des dépendances, les fichiers de signature, l’espace disque et le paquet de résultats exportable.
Voir les commandes de build
FASTLANE
Pipeline automatisé
Distinguez l’environnement Ruby, les plugins, les paramètres du lane et les erreurs renvoyées par Xcode. Conservez le log complet, pas seulement sa dernière ligne.
Vérifier la sortie d’automatisation
TRANSFER
Transfert de fichiers
Empaquetez d’abord les artefacts et générez leur valeur de contrôle, puis transférez l’archive. Évitez de déplacer un répertoire de build ou un cache de dépendances encore en cours d’écriture.
Voir l’ordre de transfert
SESSION
Session de développement distant
Vérifiez la stabilité du réseau local, la reprise de la tâche après déconnexion et la fermeture de la session interactive ainsi que le nettoyage des fichiers temporaires avant de quitter l’appareil.
Vérifier les limites de session
MLX
Environnement MLX
Vérifiez la mémoire unifiée, les fichiers de modèles, l’environnement isolé et les journaux d’expérience. Ne jugez pas l’environnement à partir d’un chiffre de vitesse impossible à vérifier.
Vérifier l’environnement d’expérience
Références de première connexion
Échec SSH : vérifiez chaque étape de la poignée de main
Conservez d’abord l’erreur brute, puis ne modifiez qu’une variable à la fois. Changer simultanément le nom d’utilisateur, le port et la clé empêche d’identifier la cause.
Droits de la clé
Exécutez localement chmod 600 ~/.ssh/oakvps_key. Si la clé privée est lisible par d’autres utilisateurs, le client SSH refusera de l’utiliser avant de lancer l’authentification.
Empreinte de l’hôte
Lors de la première connexion, comparez l’empreinte affichée dans le terminal avec les informations de connexion de la console avant de confirmer. Si les informations de l’hôte changent, ne supprimez pas simplement l’ancienne entrée pour ignorer la vérification.
Nom d’utilisateur
Utilisez le nom d’utilisateur système indiqué dans les informations de connexion de la commande. Ne remplacez pas ce nom par votre adresse e-mail ou le nom d’utilisateur de votre ordinateur local.
Port
Indiquez explicitement le port fourni dans les informations de connexion, par exemple ssh -p 22 user@host. Un délai d’attente survient généralement avant l’authentification ; un refus d’accès intervient généralement pendant l’authentification.
Accès réseau
Vérifiez que le réseau de l’entreprise, le VPN, le pare-feu local et la politique de sortie autorisent le port cible. Vous pouvez tester depuis un réseau de confiance, mais ne transférez pas d’identifiants de projet sur un réseau non fiable.
Première vérification
Après une connexion réussie, exécutez d’abord whoami,sw_vers et df -h, notez l’utilisateur, la version du système et l’espace disque disponible, puis importez les fichiers du projet.
Interpréter les résultats des commandes
Examinez séparément les sorties de connexion, de build et d’automatisation
La dernière ligne du terminal n’est généralement qu’un résultat, pas forcément la cause. Les trois séries de commandes ci-dessous vérifient respectivement l’identité de connexion, le point d’entrée du build Xcode et l’état du lane fastlane. Remplacez les paramètres d’exemple par vos informations de connexion, votre workspace et votre scheme.
- Connexion réussieLe nom d’utilisateur distant, la version du système et les informations disque sont renvoyés.
- Point d’entrée du build valideXcode identifie correctement le workspace, le scheme et la plateforme cible.
- Pipeline automatisé lisibleLes erreurs de Bundler, des plugins et du lane conservent chacune leur contexte complet.
Vérification de la connexion et de l’environnement
$ ssh -i ~/.ssh/oakvps_key -p 22 oak@203.0.113.10
$ whoami
oak
$ sw_vers -productVersion
15.x
$ df -h /Point à observer :Si la commande renvoie déjà le nom d’utilisateur distant, le réseau et l’authentification ont fonctionné. Orientez alors le diagnostic vers les droits système ou l’environnement du projet.
Point d’entrée du build Xcode
$ xcode-select -p
/Applications/Xcode.app/Contents/Developer
$ xcodebuild -version
Xcode 16.x
$ xcodebuild -workspace App.xcworkspace \
-scheme App \
-destination 'generic/platform=iOS' \
build | tee build.logPoint à observer :Vérifiez d’abord le répertoire développeur, puis le workspace et le scheme. Conservez build.log, au lieu de copier uniquement le résumé de l’échec final.
Extrait de sortie fastlane
$ bundle exec fastlane lanes
$ bundle exec fastlane ios build \
--verbose 2>&1 | tee fastlane.log
[09:24:18]: Driving the lane 'ios build'
[09:24:19]: Resolving package dependenciesPoint à observer :La liste des lanes confirme que le point d’entrée des dépendances Ruby est disponible. En cas d’échec ultérieur, recherchez la première erreur apparue dans le log, plutôt que de regarder uniquement le code de sortie.
Diagnostic d’échec du build
Vérifiez les dépendances avant de réinstaller tout l’environnement
Les versions, caches, signatures, l’espace disque et les logs s’influencent mutuellement. L’ordre ci-dessous limite les modifications inutiles et permet au prochain intervenant de reproduire le même problème.
| Ordre | Élément vérifié | À exécuter ou consigner | Critère d’évaluation |
|---|---|---|---|
| 01 | Version de Xcode | xcodebuild -version et xcode-select -p |
La chaîne d’outils requise par le projet correspond au répertoire actif, sans divergence entre la ligne de commande et l’interface graphique. |
| 02 | Cache des dépendances | Consignez d’abord les fichiers de verrouillage, puis vérifiez l’état de Swift Package, CocoaPods ou des caches propres au projet. | Les fichiers de verrouillage n’ont pas été modifiés par inadvertance. Nettoyez uniquement le cache lié à l’erreur actuelle et conservez les dépendances réutilisables. |
| 03 | Éléments de signature | Vérifiez la cible, l’identifiant de bundle, la validité du certificat et la correspondance avec le provisioning profile. | Les éléments correspondent à la cible actuelle ; les mots de passe et contenus privés ne figurent ni dans les logs, ni dans le dépôt, ni dans les pièces jointes du ticket. |
| 04 | Espace disque | df -h, la taille du répertoire du projet et celle de DerivedData. |
Les répertoires de build, dépendances, archives et fichiers temporaires disposent de suffisamment d’espace ; toute croissance anormale est identifiée séparément. |
| 05 | Log complet | Utilisez tee pour afficher et enregistrer la sortie simultanément, en consignant la commande, l’heure et le code de sortie. |
Le log contient la première erreur, son contexte et l’état de sortie final ; un autre ingénieur peut reproduire le problème avec la même commande. |
Comparez d’abord les fichiers de verrouillage, puis videz le cache
Si la résolution des dépendances change soudainement, comparez les fichiers de verrouillage avant et après, la configuration des sources de paquets et les résultats réseau. Ne supprimez le cache concerné qu’après avoir confirmé qu’il est corrompu, afin de préserver la reproductibilité.
Distinguez les éléments manquants d’une incompatibilité de cible
L’erreur peut provenir d’un certificat indisponible, d’un profil qui ne correspond pas à l’identifiant de bundle ou d’une mauvaise cible de build. Notez le code d’erreur et le nom de la cible, sans inscrire de mot de passe de certificat, de clé privée ou de données de signature complètes dans le ticket.
Conservez le contexte complet du premier échec
Les exécutions répétées peuvent modifier les caches et les fichiers temporaires. Après le premier échec, sauvegardez d’abord les logs, la commande, l’état du workspace et les informations disque, puis retestez avec une seule variable modifiée.
Sessions et transfert d’artefacts
Rendez la session de développement distant et la livraison des fichiers récupérables séparément
La fenêtre distante n’est qu’un point d’accès et ne doit pas être le seul emplacement de l’état de la tâche. Les commandes, logs, artefacts et valeurs de contrôle doivent être enregistrés dans des répertoires clairement définis.
Session distante
Vérifiez l’état avant la connexion et avant de partir
- 01Préparer la connexion
Vérifiez le réseau local, l’empreinte de l’hôte, le nom d’utilisateur cible et la provenance des fichiers du projet. N’importez les fichiers sensibles que lorsque la tâche l’exige.
- 02Exécuter les tâches longues hors fenêtre
Faites tourner le build ou l’expérience dans un gestionnaire de session récupérable et écrivez simultanément la sortie standard dans un fichier log.
- 03Quitter avant de partir
Vérifiez que les fichiers sont enregistrés et que l’état de la tâche est consigné, puis fermez l’interface graphique ou la session SSH. Ne laissez pas de modifications non enregistrées dans la fenêtre.
- 04Révoquer les accès
Après le départ d’un membre de l’équipe ou la fin d’une tâche, révoquez les clés et accès devenus inutiles, puis vérifiez les répertoires partagés.
Transfert de fichiers
Traitez séparément les artefacts, les logs et les données sensibles
- 01Arrêter les écritures
Vérifiez que le build est terminé avant d’archiver les artefacts. Ne transférez pas un répertoire ou un fichier de base de données encore en cours de génération.
- 02Générer un inventaire
Consignez les noms de fichiers, la version du build, la version de l’environnement, la commande de génération et la valeur de contrôle afin que le destinataire puisse vérifier l’intégrité.
- 03Vérifier après téléchargement
Décompressez localement l’archive et contrôlez les fichiers essentiels. Vérifiez qu’elle ne contient pas un répertoire vide et qu’aucun log nécessaire ne manque.
- 04Nettoyer les fichiers sensibles
Supprimez selon la politique de l’équipe les clés temporaires, jetons, éléments de signature et copies de modèles inutiles, tout en conservant les enregistrements de build partageables.
Vérifications des expériences MLX
Notez d’abord le modèle, l’environnement et les limites mémoire avant d’évaluer les résultats
MLX utilise la mémoire unifiée d’Apple Silicon. Les fichiers de modèles, l’utilisation à l’exécution, la longueur du contexte et les résultats intermédiaires influencent ensemble l’espace disponible. Ne vous fiez donc pas uniquement à la taille du modèle ni à la durée d’une seule exécution pour évaluer les performances.
Les trois offres utilisent un nœud physique dédié : l’offre Essentiel inclut M4, 16 Go de mémoire et 256 Go de stockage ; l’offre Avancée inclut M4, 24 Go de mémoire et 512 Go de stockage ; l’offre Haute mémoire inclut M4 Pro, 64 Go de mémoire et 2 To de stockage. Choisissez selon l’utilisation mesurée du modèle, du jeu de données et des tâches parallèles.
Isoler l’environnement d’expérience
Fixez l’environnement Python et les versions des dépendances pour chaque projet, puis conservez une liste reproductible. N’installez pas plusieurs versions expérimentales dans l’environnement système.
Vérifier la taille des fichiers de modèles
Consignez séparément la taille des paquets téléchargés, des fichiers décompressés, du cache et des répertoires de sortie. Réservez de l’espace aux fichiers temporaires pour éviter une interruption par manque d’espace.
Choisir la capacité mémoire
Consignez l’utilisation maximale depuis le Moniteur d’activité ou la ligne de commande. En cas de pression mémoire persistante, réduisez le parallélisme, la taille de la tâche ou ajustez la configuration au lieu de relancer simplement l’expérience.
Conserver les logs d’expérience
Notez la version du code et des dépendances, l’identifiant du modèle, les paramètres, un résumé des entrées, l’emplacement des sorties et les anomalies afin de permettre une reproduction à l’identique.
Avant d’envoyer une demande au support
Transformez votre ticket en compte rendu reproductible
Le support doit connaître la commande concernée, le nœud, l’étape et la période du problème. Plus les informations sont précises, plus le diagnostic peut commencer directement.
Identifiant de commande
Indiquez l’identifiant visible dans la console. N’envoyez ni justificatif de paiement ni données de paiement complètes.
Requis
Nœud physique
Indiquez le nœud utilisé par la commande et le point d’entrée actuel afin de distinguer le chemin réseau de l’environnement concerné.
Requis
Heure de survenue
Utilisez une heure avec fuseau et précisez si le problème est continu, intermittent ou limité à une seule tâche.
Requis
Étapes de reproduction
Depuis un état normal, listez dans l’ordre les commandes, paramètres, résultats attendus et résultats réels, sans omettre les opérations intermédiaires.
Requis
Logs expurgés
Joignez le contexte complet de l’erreur et le code de sortie, en retirant les clés privées, jetons, mots de passe de certificats, identifiants de dépôt et contenus sensibles du projet.
RecommandéBesoin d’un Mac dans le cloud prêt à l’emploi ?
Choisissez Oak M4, Oak M4 Plus ou Oak M4 Pro et louez un nœud physique dédié selon la durée de votre tâche. Après la commande, consultez la commande, les informations de connexion et les tickets d’assistance dans la console.