Connexion · Configuration · Dépannage

Identifiez le problème avant de reprendre vos builds

Retrouvez ici les instructions d’utilisation de votre Mac dans le cloud. Pour une première connexion, commencez par les quatre guides ci-dessous. Si votre instance rencontre un problème, recherchez le symptôme ou accédez directement au diagnostic.

Questions fréquentes
Après la livraison

Vérifiez d’abord la connexion et les accès

MacFTP fournit un Mac physique dédié équipé d’Apple Silicon, sous macOS natif et non virtualisé. Pour les étapes ci-dessous, utilisez l’adresse IP, le nom d’utilisateur et les informations de connexion indiqués dans la fiche de l’instance sur le portail. Le numéro de commande ne remplace pas le nom d’utilisateur.

Connexion SSH

Ouvrez un terminal local et remplacez le nom d’utilisateur, l’adresse IP et le port de la commande par les valeurs indiquées dans la fiche de l’instance. Lors de la première connexion, vérifiez l’empreinte de l’hôte avant de lui faire confiance.

ssh -p PORT USER@NODE_IP

Interprétez le message d’erreur : en cas de délai d’attente, vérifiez d’abord le réseau. Pour « Connection refused », vérifiez le port et l’état de l’instance. Pour « Permission denied », vérifiez le compte et le mode d’authentification, sans essayer des mots de passe au hasard.

Vérifier la connexion

VNC / Partage d’écran

Consultez les options de connexion graphique dans la fiche de l’instance sur le portail. Dans votre client, renseignez l’adresse, le port et les identifiants fournis. Ne partez pas du principe que le mot de passe SSH est aussi celui de la session graphique.

Si l’écran reste noir, déconnectez-vous puis reconnectez-vous, en vérifiant que vous n’ouvrez pas une ancienne session en double. Si SSH fonctionne, sauvegardez les journaux de build et vérifiez que le système répond avant d’envisager un redémarrage complet.

L’accès graphique dans le navigateur est disponible uniquement dans la fiche de l’instance après connexion. Les informations d’accès ne sont pas affichées sur cette page publique.

Vérifier la session

Mots de passe et clés

Après la première connexion, changez le mot de passe du compte courant avec passwd. Générez une clé SSH localement et ajoutez uniquement la clé publique au fichier distant ~/.ssh/authorized_keys. Gardez la clé privée sur votre machine.

Réglez les permissions du répertoire ~/.ssh sur 700 et celles de authorized_keys sur 600. Gardez la session actuelle ouverte, puis vérifiez la connexion par clé dans un autre terminal.

Ne fermez pas la session initiale et ne désactivez pas l’authentification existante avant d’avoir terminé les vérifications. N’incluez ni clé privée, ni mot de passe, ni information de récupération dans un ticket.

Signaler un problème d’accès

Xcode et outils en ligne de commande

Exécutez d’abord xcode-select -p et xcodebuild -version pour vérifier l’environnement actuel. Pour utiliser l’interface graphique, consultez les versions de Xcode présentes dans Applications depuis une session à distance.

Pour n’installer que les outils en ligne de commande, exécutez xcode-select --install. La création d’archives iOS nécessite toutefois Xcode complet. Après l’installation d’une nouvelle version, terminez son premier lancement et l’installation des composants nécessaires avant de l’utiliser en CI.

Si plusieurs versions coexistent, sélectionnez le bon répertoire selon son chemin réel. Changer uniquement le nom de l’application ne suffit pas si le Runner utilise toujours l’ancien répertoire développeur.

Voir les commandes de sélection
Du local au cloud

Trois étapes, chacune avec un contrôle

Commencez par réussir un build unique du même commit, puis activez les tâches automatiques. Les durées ci-dessous sont indicatives et ne constituent pas un engagement de livraison. Le volume du dépôt, le réseau, le téléchargement des dépendances et la préparation de la signature peuvent allonger le processus.

01 / Données

Synchronisez le code, pas les caches de build

Prévoyez 15 à 45 minutes. Les dépôts contenant de nombreux fichiers volumineux peuvent prendre plus de temps.

Dans la mesure du possible, récupérez un commit précis depuis le dépôt Git. Pour transférer des fichiers non commités, utilisez SFTP ou rsync. Excluez DerivedData, le répertoire build du projet et les journaux locaux afin de ne pas importer d’anciens chemins ni de caches obsolètes.

Vérifiez la liste des fichiers avec dry-run avant de lancer la synchronisation. Dans l’exemple, remplacez USER et NODE_IP par les valeurs fournies avec l’instance. Si le port SSH est personnalisé, configurez-le aussi.

rsync -av --dry-run \
  --exclude='DerivedData/' \
  --exclude='build/' \
  ./ USER@NODE_IP:~/project/
git rev-parse HEAD
git status --short

Validation : les deux côtés utilisent le même commit, les ressources sont présentes et aucune configuration sensible n’a été ajoutée au dépôt.

02 / Outils

Recréez les dépendances et la signature

Prévoyez 30 à 90 minutes. Le premier téléchargement peut prendre plus longtemps.

Notez les versions locales de Xcode, des SDK, de Homebrew et des dépendances de vos scripts. Vérifiez d’abord la présence de Homebrew avec brew --version. Si le projet contient un Brewfile, restaurez ensuite les dépendances à partir de ce fichier.

Transférez les fichiers p12 et les profils de provisionnement nécessaires à la signature via une connexion chiffrée. Importez le certificat dans un trousseau dédié et placez les profils dans le répertoire de l’utilisateur de build. N’inscrivez aucun mot de passe dans le dépôt ou les journaux de build.

brew --version
xcodebuild -version
xcodebuild -showsdks
security find-identity -v -p codesigning

Validation : le SDK répond aux exigences du projet, l’identité de signature est valide et l’archive manuelle se termine correctement.

03 / Intégration CI

Enregistrez le Runner avant d’activer les builds automatiques

Prévoyez 20 à 60 minutes, hors durée des tests du projet.

Suivez les instructions générées par votre plateforme de code pour installer un Runner GitHub Actions autohébergé ou un GitLab Runner. Le jeton d’enregistrement ne sert qu’à la configuration. Ne stockez pas le mot de passe de la machine dans vos workflows.

Vérifiez les étiquettes self-hosted, macOS et ARM64. Lancez d’abord manuellement un build sur un commit précis, puis contrôlez le répertoire de travail, le chemin des artefacts et les permissions de signature avant d’activer les builds automatiques sur les branches.

uname -m
sw_vers -productVersion
xcode-select -p
git rev-parse HEAD

Validation : le Runner est en ligne, le commit ciblé est correct, l’archive peut être récupérée et les journaux ne contiennent aucun identifiant sensible.

Lorsque plusieurs tâches s’exécutent sur le même nœud physique, elles partagent toujours le processeur, la mémoire unifiée et le SSD. Limitez d’abord la concurrence, puis augmentez-la progressivement pour éviter de confondre une compétition entre tâches et un problème du nœud.

À exécuter étape par étape

Commandes utiles : vérifiez les prérequis

Les noms de répertoires et de fichiers sont des exemples : avant l’exécution, remplacez-les par les chemins réellement présents sur la machine. Les commandes utilisant sudo nécessitent des droits administrateur. Ne copiez pas de commande contenant un mot de passe dans un journal public.

Sélectionner le répertoire développeur Xcode

Cet exemple suppose que /Applications/Xcode.app existe. Si plusieurs versions sont installées, vérifiez le chemin de l’application, puis contrôlez la version et le SDK après le changement. Pour utiliser une autre version uniquement pendant une tâche, définissez DEVELOPER_DIR dans cette tâche.

Sélection et vérification 
sudo xcode-select --switch /Applications/Xcode.app/Contents/Developer
xcode-select -p
xcodebuild -version
xcodebuild -showsdks

Importer un p12 dans le trousseau de build

Créez d’abord un trousseau dédié nommé build.keychain-db et déverrouillez-le dans la session de l’utilisateur qui exécutera la tâche. Lors de l’importation, saisissez le mot de passe du p12 à l’invite système. La visibilité du certificat ne garantit pas que les droits d’accès à la clé privée conviennent à la CI.

Import et vérification 
security import ./signing.p12 \
  -k "$HOME/Library/Keychains/build.keychain-db" \
  -T /usr/bin/codesign
security find-identity -v -p codesigning \
  "$HOME/Library/Keychains/build.keychain-db"

Gérer le Runner avec launchd

Cette procédure s’applique à un répertoire GitHub Actions Runner déjà enregistré et contenant svc.sh. Le script installe et démarre le service, géré par launchd. Pour GitLab Runner, utilisez ses propres commandes de service et non ce script.

À lancer dans le répertoire du Runner 
./svc.sh install
./svc.sh start
./svc.sh status
launchctl list | grep -i runner

La présence d’une tâche dans launchd confirme uniquement que le service est enregistré. Vérifiez aussi sur la plateforme de code que le Runner est en ligne et lancez réellement un build. Si la tâche nécessite une interface graphique ou le trousseau, vérifiez également l’état de la session utilisateur.

Commande et durée de location

Vérifiez séparément l’échéance et le paiement

Le service se règle à l’avance par jour, semaine, mois ou trimestre, en un seul paiement pour la durée choisie. L’état du compte, du paiement et de l’instance correspond à trois informations distinctes. Pour signaler un problème, notez le numéro de commande et celui de l’instance.

Comment renouveler et vérifier que mes données seront conservées ?

Connectez-vous au portail et consultez la date d’expiration ainsi que l’option de renouvellement dans la commande associée à l’abonnement ou à l’instance. Après le renouvellement de l’abonnement existant, vérifiez que la durée a bien été prolongée. Créer une nouvelle commande d’instance ne renouvelle pas le nœud actuel. Si la date n’est pas mise à jour après le paiement, conservez le justificatif de transaction et ouvrez un ticket. Pensez à sauvegarder vous-même les données importantes.

Recevrai-je un rappel d’échéance, et quelle date dois-je retenir ?

Fiez-vous à la date d’expiration de la commande affichée dans le portail et vérifiez le fuseau horaire indiqué. Assurez-vous que l’adresse e-mail du compte est accessible et consultez les courriers indésirables. La réception d’un e-mail ne doit pas être votre seul moyen de vérifier la durée restante. Il est conseillé de créer un rappel dans le calendrier de votre équipe afin de renouveler le service ou de transférer votre code, vos certificats et vos artefacts avant l’échéance.

Quels moyens de paiement et quelle devise sont acceptés ?

Seuls USDT-TRC20 et Visa / Mastercard / Amex (via Stripe) sont acceptés. Tous les paiements sont en dollars américains (USD) ; les moyens effectivement disponibles sont ceux renvoyés par l’interface de paiement. Pour un paiement sur la blockchain, vérifiez le réseau, le montant et les informations de la page de paiement. Pour un paiement par carte, fiez-vous au résultat indiqué dans la commande. Pour toute anomalie, communiquez le numéro de commande ou le hash de transaction, jamais le numéro complet de la carte, le code de vérification ou la clé privée du portefeuille.

Comment traiter un problème de paiement, un remboursement ou un reçu ?

Commencez par vérifier la facture, l’historique des paiements et les reçus disponibles dans le portail. Les conditions de remboursement, son champ d’application et les règles associées figurent dans les Conditions d’utilisation. Supprimer la configuration de connexion locale ou cesser d’utiliser la machine ne remplace pas une demande de remboursement. En cas de doute sur un débit en double, indiquez les commandes et références de transaction concernées dans un ticket via le portail.

Voir mes commandes sur le portail
Conservez les éléments de diagnostic

Diagnostiquez du problème le plus local au plus large

Déterminez d’abord si le problème concerne un client, une session ou l’ensemble du nœud. Notez l’erreur exacte et l’heure à laquelle elle s’est produite. Effectuez chaque vérification l’une après l’autre ; évitez de modifier le réseau, de réinitialiser le mot de passe et de redémarrer en même temps, au risque de rendre le problème impossible à suivre.

Réseau et destination

Vérifiez à nouveau l’adresse IP, le port et le nom d’utilisateur dans la fiche de l’instance. Essayez un autre réseau local et contrôlez votre proxy, votre pare-feu et les règles de sortie de votre entreprise. L’échec d’une requête ICMP ne suffit pas à conclure que SSH est inaccessible : vérifiez aussi le port réellement utilisé.

ssh -vv -o ConnectTimeout=10 -p PORT USER@NODE_IP

À noter : délai d’attente, connexion refusée ou échec d’authentification. Avant de partager les journaux de diagnostic, masquez votre nom d’utilisateur local, les chemins sensibles et les informations d’authentification.

Disque et caches de build

Commencez par vérifier l’espace disponible avec df -h /, puis mesurez la taille du cache avec du -sh ~/Library/Developer/Xcode/DerivedData. Arrêtez les builds concernés avant de nettoyer les fichiers du projet afin de ne pas supprimer une archive en cours d’écriture.

À conserver : les artefacts à récupérer, les fichiers de signature et les journaux nécessaires. Après le nettoyage, réessayez avec le même commit pour vérifier qu’il ne s’agit pas d’une dépendance corrompue ou d’un chemin incorrect.

Alertes système et chaîne d’outils

Depuis une session graphique, vérifiez qu’aucune boîte de dialogue système ni invitation au premier lancement de Xcode n’attend une réponse. Exécutez sw_vers, xcodebuild -version et xcodebuild -showsdks pour confirmer que l’environnement utilisé par la CI correspond à vos attentes.

Mettez d’abord les tâches en pause et effectuez une sauvegarde, puis décidez si vous souhaitez mettre à jour le système ou la chaîne d’outils. Ne changez pas le chemin Xcode pendant la création d’une archive.

Rétablir la session et redémarrer

Fermez le client distant, puis reconnectez-vous. Si SSH reste accessible, vérifiez uptime et les tâches en cours. Ne redémarrez toute la machine qu’après avoir confirmé que c’est nécessaire ; connectez-vous alors au portail et utilisez l’option de redémarrage dans la fiche de l’instance.

Le redémarrage interrompt les builds et les connexions à distance. Sauvegardez d’abord les journaux et les artefacts que vous pouvez récupérer. Si l’instance reste inaccessible ou qu’aucune option ne fonctionne, ouvrez un ticket plutôt que de multiplier les demandes de redémarrage.

Besoin d’aide supplémentaire ?

Ouvrez un ticket avec les bonnes informations

Connectez-vous au portail pour envoyer un ticket technique qui pourra être associé à votre commande et à votre instance. Si vous ne pouvez pas vous connecter ou souhaitez échanger avant de commander, écrivez à support@macftp.com. Vous trouverez les autres moyens de contact sur la page dédiée.

  • Identifier l’instance : numéro de commande, numéro d’instance, nœud et modèle. Le nœud se trouve à Singapour, Tokyo, Séoul ou Hong Kong. Indiquez le nom complet du modèle affiché dans la fiche de l’instance.
  • Décrire la situation : date et heure avec fuseau horaire, message d’erreur complet, étapes pour reproduire le problème et état des connexions SSH et graphique.
  • Éviter les échanges inutiles : vérifications déjà effectuées, changements récents et extraits de journaux expurgés. N’envoyez ni mot de passe, ni clé privée, ni mot de passe de fichier p12, ni justificatif de paiement complet.
Se connecter au portail et ouvrir un ticket Voir les informations de contact Louer un Mac dans le cloud