De SSH et l’interface graphique aux transferts de fichiers, à Xcode, Runner, fastlane et au réseau des nœuds : reproduisez le problème avec des commandes, puis corrigez la configuration ou ouvrez un ticket.
$ ssh -v "$MAC_USER@$MAC_HOST"
debug1: Authentication succeeded
$ xcodebuild -version
Xcode toolchain ready
$ scutil --dns | grep nameserver
Resolver path verified
Ouvrez l’instance correspondante dans la console et vérifiez l’adresse de l’hôte, le nom d’utilisateur et les identifiants initiaux. La première connexion sert à vérifier l’hôte, ouvrir la session, puis passer à l’authentification par clé.
Vérifiez d’abord que l’instance fonctionne normalement, puis enregistrez séparément l’adresse de l’hôte et le nom d’utilisateur affichés dans la console dans des variables d’environnement locales. N’inscrivez jamais de mot de passe, de clé privée ou d’identifiants complets dans un dépôt, une conversation ou des journaux automatisés.
export MAC_HOST="Adresse de l’hôte affichée dans la console"
export MAC_USER="Nom d’utilisateur affiché dans la console"
test -n "$MAC_HOST" && test -n "$MAC_USER" && echo "connection variables ready"Après la connexion, comparez l’empreinte affichée dans le terminal avec les informations de la console. Si l’adresse de l’hôte change, si l’empreinte change après une réinstallation ou si une ancienne entrée est enregistrée localement, ne l’ignorez pas : vérifiez d’abord qu’il s’agit toujours du même appareil.
ssh -v "$MAC_USER@$MAC_HOST"
ssh-keygen -F "$MAC_HOST"Nous recommandons de générer une clé Ed25519 distincte pour votre Mac dans le cloud afin de faciliter sa rotation et sa révocation. Après avoir installé la clé publique, gardez la session actuelle ouverte et vérifiez la connexion par clé dans un second terminal avant de fermer la première session.
ssh-keygen -t ed25519 -a 64 -f "$HOME/.ssh/macrents_build"
cat "$HOME/.ssh/macrents_build.pub" | ssh "$MAC_USER@$MAC_HOST" 'umask 077; mkdir -p ~/.ssh; cat >> ~/.ssh/authorized_keys'
ssh -i "$HOME/.ssh/macrents_build" "$MAC_USER@$MAC_HOST"Définissez pour cette instance un alias, un chemin de clé et des paramètres de maintien de connexion dédiés. Une fois connecté, notez la version de macOS, l’espace disque disponible, l’utilisateur courant et l’heure système afin de détecter rapidement toute évolution de l’environnement en cas d’échec de build.
sw_vers
whoami
date
df -h /
uptimeEn cas de délai d’attente, vérifiez d’abord le réseau local, le port, le routage du nœud et les restrictions d’adresse source. Si vous voyez Permission denied vérifiez le nom d’utilisateur, le fichier de clé, ses permissions et les autorisations côté serveur. Ne modifiez pas sans cesse le DNS après une erreur d’authentification et ne réinitialisez pas continuellement les identifiants lorsque le réseau est inaccessible.
Privilégiez SSH pour les builds et l’automatisation ; utilisez un bureau distant graphique pour déboguer l’interface, les simulateurs ou les outils de bureau ; utilisez un transfert de fichiers reprenable pour synchroniser des projets et des artefacts en volume.
Idéal pour récupérer des dépôts, installer des dépendances, lancer des builds et gérer des tâches persistantes. En cas d’instabilité, activez le maintien de connexion et utilisez les journaux détaillés pour localiser l’interruption : négociation, authentification ou session.
ssh -vvv -o ServerAliveInterval=30 -o ServerAliveCountMax=4 "$MAC_USER@$MAC_HOST"Accédez au point d’entrée graphique depuis la console pour déboguer Xcode, observer les simulateurs et utiliser les outils nécessitant un bureau. En cas de latence, réduisez d’abord la résolution et la fréquence d’actualisation, puis comparez avec la latence du terminal afin de distinguer l’encodage vidéo d’un problème réseau global.
Pour quelques fichiers, utilisez scp; pour les grands répertoires et les caches de build, préférez rsync. Excluez avant le transfert les données dérivées, archives temporaires et caches de dépendances afin d’éviter de retransmettre inutilement des contenus reconstructibles à l’international.
rsync -azP --partial --exclude DerivedData/ ./project/ "$MAC_USER@$MAC_HOST:~/workspace/project/"Ne dépendez pas d’un seul terminal au premier plan pour les builds longs. Utilisez un gestionnaire de sessions ou les services macOS pour maintenir les tâches, et écrivez régulièrement les journaux dans un répertoire contrôlé. Révoquez les clés publiques et jetons d’accès devenus inutiles.
tmux new -s build
tmux attach -t build
tail -n 200 "$HOME/logs/build.log"La version de Xcode affichée dans l’interface graphique peut différer du répertoire de développement sélectionné en ligne de commande. Notez d’abord le chemin, la version, le SDK, le simulateur et l’environnement de signature, puis relancez un build minimal.
xcode-select -p
xcodebuild -version
xcodebuild -showsdks
xcrun simctl list devices available
xcrun --find swift
swift --version
security list-keychains -d user
security find-identity -v -p codesigningxcode-select -p doit pointer vers le Xcode requis par ce build. Si le chemin est incorrect, arrêtez Runner, changez de répertoire, puis redémarrez-le afin que les tâches en cours n’héritent pas de l’ancien environnement.
Si le SDK cible n’apparaît pas dans la sortie de -showsdks , modifier les paramètres du projet ne complétera pas la chaîne d’outils. Pour les tâches de simulateur, vérifiez aussi l’état de l’appareil, la version du runtime et l’espace disque.
La présence d’une identité de signature ne signifie pas qu’un processus automatisé peut accéder à la clé privée. Comparez l’utilisateur, la liste de recherche des trousseaux et l’état de déverrouillage du terminal interactif et du service Runner.
Fixez d’abord l’espace de travail, le scheme, la configuration et la destination, puis désactivez les scripts sans rapport. Conservez le code de sortie complet et les dernières lignes du journal ; ne gardez pas uniquement la dernière erreur.
set -o pipefail
xcodebuild -workspace Project.xcworkspace -scheme Project -configuration Release -destination 'generic/platform=macOS' clean build | tee "$HOME/logs/xcode-build.log"
printf 'exit_code=%s\n' "$?"Les Runner auto-hébergés et les agents persistants doivent fixer l’utilisateur, le répertoire de travail, le chemin de la chaîne d’outils, les limites du cache et le mode d’accès aux clés. Faites d’abord réussir une tâche minimale de façon stable, puis réactivez progressivement concurrence, cache et distribution.
Générez une fois les informations d’enregistrement dans les paramètres du projet ou de l’organisation, puis enregistrez Runner sur le Mac dans le cloud avec un utilisateur système dédié. Les labels doivent au moins distinguer le système, la catégorie de puce et l’usage ; acheminez les tâches macOS vers le nœud correspondant.
whoami
xcode-select -p
printenv | sort
df -h "$HOME"Lors de l’enregistrement, choisissez un mode d’exécution adapté à macOS et limitez la provenance des tâches avec des labels protégés. L’utilisateur du service doit accéder au répertoire du projet et aux trousseaux nécessaires, sans obtenir de privilèges système étrangers au build.
git status --short
git rev-parse HEAD
shasum -a 256 "$HOME/artifacts/app.zip"
du -sh "$HOME/build-cache"Confiez votre agent interne ou autre agent de build aux services macOS. Définissez clairement l’utilisateur de démarrage, le fichier de variables d’environnement, la sortie standard et la stratégie de redémarrage. Ne dépendez pas d’une session de bureau distant constamment connectée.
launchctl list | grep build
ps aux | grep '[b]uild-agent'
lsof -nP -iTCP -sTCP:ESTABLISHED
tail -n 200 "$HOME/logs/agent.log"Ne réinstallez pas toutes les dépendances d’emblée. Identifiez d’abord l’étape concernée — préparation de la signature, archivage, export ou envoi — puis recueillez ses entrées, son code de sortie et ses journaux désensibilisés.
| Couche | Symptôme courant | Première vérification | Principe de traitement |
|---|---|---|---|
| Certificats | Identité de signature introuvable, ou aucune identité | security find-identity -v -p codesigning | Vérifier le trousseau cible, la validité du certificat et l’association avec la clé privée |
| Profil de provisioning | Identifiant incompatible, capacités incohérentes | Identifiant cible, équipe, capacités requises et contenu du fichier | Ne pas mélanger les profils de projets ou d’environnements différents |
| Permissions du trousseau | Build possible dans le terminal, signature impossible dans Runner | Utilisateur, liste de recherche, état de déverrouillage et contrôle d’accès à la clé privée | Limiter le processus automatisé aux éléments de signature nécessaires à la tâche |
| Variables d’environnement | Exécution interactive réussie, paramètres absents dans le service | printenv : différences après désensibilisation et configuration de démarrage du service | Injecter explicitement les variables ; ne pas dépendre des fichiers de configuration du Shell interactif |
| Journaux d’envoi | Archivage réussi, mais envoi interrompu ou état non nul | Code de sortie complet, nombre de tentatives, taille du fichier et chronologie réseau | Valider d’abord l’artefact, puis distinguer le problème d’envoi du problème de build |
La cause la plus fréquente est un utilisateur différent, ou un service qui n’a pas hérité de la liste de recherche des trousseaux de la session interactive. Enregistrez séparément whoami , security list-keychains -d user et la sortie des identités de signature, puis comparez les deux environnements. N’élargissez pas les permissions de toutes les clés privées pour masquer un problème de séparation des utilisateurs.
Avec le même commit, le même chemin Xcode et le même répertoire de travail, affichez séparément dans le terminal interactif et Runner la liste désensibilisée des noms de variables. Comparez uniquement leur présence, sans afficher les valeurs des jetons. Si elles sont toutes présentes, vérifiez le répertoire, le type de Shell, les versions des dépendances et l’utilisateur d’exécution.
Conservez le nom de la lane, l’étape en échec, le code de sortie complet, les versions de Xcode et fastlane, les heures de début et de fin, le contexte final et la commande reproductible. Supprimez les jetons, mots de passe de certificats, clés privées, informations de session et données personnelles avant l’envoi. Une capture de la seule dernière ligne d’erreur suffit rarement.
Choisissez un nœud selon la localisation de l’équipe, l’origine du code et des dépendances, la destination des artefacts et le chemin réel. Ne vous fiez pas à une seule mesure : comparez au minimum latence aller-retour, pertes, résolution DNS et variations de routage, en notant la période de test.
Adapté aux équipes et chaînes de dépendances d’Asie du Sud-Est. Si la latence augmente soudainement, comparez le réseau du bureau, le réseau mobile et une autre sortie afin d’identifier un changement de routage local.
Adapté aux projets japonais et nord-asiatiques. Pour diagnostiquer une connexion internationale, notez simultanément la latence directe, le nombre de sauts et le débit de transfert ; ne vous fiez pas seulement à la fluidité visuelle du bureau distant.
Adapté aux accès depuis la Corée et les régions voisines. Si SSH fonctionne mais que les gros fichiers sont instables, vérifiez les pertes, le MTU, le proxy local et le nombre de transferts parallèles.
Adapté à la collaboration internationale en Asie et aux équipes réparties. Si un réseau atteint la cible tandis qu’un autre expire, conservez les deux résultats de routage et indiquez le type de réseau source.
Un test court confirme l’accessibilité ; un test prolongé révèle la gigue et les pertes intermittentes. Définissez $MAC_HOST sur l’adresse de l’instance courante, puis exécutez :
ping -c 20 "$MAC_HOST"
nc -vz -w 5 "$MAC_HOST" 22
traceroute "$MAC_HOST"Si vous vous connectez avec un nom d’hôte, vérifiez d’abord la stabilité de sa résolution ; si l’adresse directe échoue également, le problème ne vient généralement pas du DNS. Notez le résolveur local et le résultat de la requête :
scutil --dns
dscacheutil -q host -a name "$MAC_HOST"
dig "$MAC_HOST"Vérifiez que le trafic sort par l’interface attendue et que le VPN, le proxy ou plusieurs cartes réseau ne modifient pas la route par défaut. Après le test, rétablissez la configuration réseau initiale et ne changez pas plusieurs variables à la fois :
route -n get "$MAC_HOST"
netstat -rn
ifconfig
networkQualitySi la négociation SSH est normale mais le transfert lent, répétez le test avec un fichier fixe et notez sa taille, la durée et le réseau client. Ne comparez pas directement des résultats issus de répertoires ou compressions différents :
time scp "$HOME/test-transfer.bin" "$MAC_USER@$MAC_HOST:~/"
shasum -a 256 "$HOME/test-transfer.bin"
ssh "$MAC_USER@$MAC_HOST" 'shasum -a 256 ~/test-transfer.bin'En cas d’anomalie, recueillez des éléments selon le réseau source, le nœud cible, le protocole et la période. Un seul test ne représente pas la qualité à long terme ; exécutez-le au moins une fois sur le réseau concerné et sur un réseau de comparaison pour localiser le problème : sortie locale, itinéraire international ou couche de connexion cible.
Les utilisateurs existants doivent de préférence se connecter à la console pour ouvrir un ticket, afin de l’associer à la commande et à l’instance. Si la console est inaccessible, envoyez un e-mail à support@macrents.com. Les deux canaux suivent le même processus d’assistance.
Vous pouvez conserver la partie nécessaire de l’adresse de l’hôte dans les journaux, mais supprimez les jetons, mots de passe, en-têtes, éléments de signature et données personnelles. Si l’assistance a besoin d’informations supplémentaires, elle précisera dans le ticket le périmètre minimal requis.
En cas de déconnexion, d’instance inaccessible ou d’échecs répétés du build, indiquez l’impact métier. Pour les questions de configuration avant achat, écrivez directement par e-mail ; pour les commandes existantes, l’état de l’hôte et les journaux, privilégiez le ticket dans la console.
Les trois formules proposent un Mac mini physique dédié, non virtualisé. Choisissez selon la concurrence des builds, la mémoire unifiée requise et la durée de location ; si une instance existante rencontre un problème, ouvrez directement un ticket depuis la console.