Première connexion
Préparez votre clé publique SSH, vérifiez le nom d’utilisateur, l’adresse de l’hôte et l’empreinte, puis choisissez la ligne de commande ou l’interface graphique dans le navigateur.
Il ne s’agit pas d’une simple liste de questions-réponses. Chaque guide suit un ordre de vérification pour vous aider à déterminer si le problème vient du réseau local, des identifiants de connexion, du service distant, de l’environnement de développement ou de la tâche elle-même.
Conçu pour les Mac mini physiques dédiés de DplyMini. Les appareils ne sont pas virtualisés : macOS est accessible avec son interface graphique et sa ligne de commande, pour le développement iOS/macOS, les builds CI/CD et les expérimentations d’inférence IA.
Une seule commande, un projet, tout l’appareil ou toutes les connexions du réseau local.
Notez l’heure, le nœud, la ligne d’erreur complète et l’opération exécutée juste avant.
Vérifiez successivement l’état du portail, la liaison locale, les identifiants, le service et le port cible.
Choisissez d’abord l’accès correspondant le mieux à votre objectif. Ne modifiez pas simultanément le réseau, les identifiants et la configuration du build : il serait difficile d’identifier la véritable cause de la résolution.
Préparez votre clé publique SSH, vérifiez le nom d’utilisateur, l’adresse de l’hôte et l’empreinte, puis choisissez la ligne de commande ou l’interface graphique dans le navigateur.
Vérifiez le chemin Xcode sélectionné, les outils en ligne de commande, les éléments de signature, les dépendances fastlane et le compte d’exécution du Runner CI.
Vérifiez l’espace du répertoire cible, les droits, les sommes de contrôle et la reprise sur interruption afin de ne pas confondre une interruption de transfert avec une panne de l’appareil.
Vérifiez successivement le DNS, la liaison sortante, le pare-feu, le port cible et le service distant, sans réinitialiser tous les paramètres réseau en une seule fois.
Vérifiez la période de commande, les relevés en dollars, l’état du paiement et les informations associées à la commande. Pour un problème d’exécution, envoyez un ticket depuis la commande concernée.
Cette séquence convient aux délais d’attente SSH, aux sessions graphiques inaccessibles, aux agents de build hors ligne et aux ports de service inaccessibles. Chaque étape répond à une seule question et son résultat doit être consigné.
Connectez-vous au portail et ouvrez la commande correspondante. Vérifiez que le nom de l’appareil, le nœud, la durée de location et l’adresse de connexion correspondent à la commande actuelle. La disponibilité est déterminée par la réponse en temps réel du portail.
La commande correspond à l’appareil cible et les informations de connexion n’ont pas été mal copiées.
Vérifiez que votre réseau local peut résoudre d’autres domaines et accéder aux services HTTPS courants. Sur un réseau d’entreprise, un Wi-Fi invité ou un environnement proxy, utilisez temporairement une liaison connue comme fonctionnelle pour comparer.
Le problème se produit-il uniquement sur un réseau sortant donné ?
Vérifiez que la configuration SSH utilise la clé privée attendue et que les droits du fichier sont appropriés. En cas d’échec d’authentification, utilisez la sortie détaillée pour confirmer quelle clé le client a réellement tentée.
La connexion a-t-elle atteint l’hôte ou a-t-elle expiré avant l’authentification ?
Si SSH fonctionne mais que l’interface graphique est interrompue, le réseau de base et l’appareil restent généralement accessibles. Vérifiez alors la session du navigateur, la résolution, le presse-papiers ou le service de bureau.
L’impact concerne-t-il tout l’appareil ou un seul service distant ?
Vérifiez que l’application écoute sur l’adresse et le port attendus et que les règles du pare-feu local ou du projet autorisent l’accès. N’attribuez pas directement l’absence de démarrage de l’application au réseau du nœud.
Le port est-il inaccessible, le service n’écoute-t-il pas ou l’application quitte-t-elle immédiatement après son lancement ?
Remplacez le nom d’hôte de la commande par l’adresse de connexion affichée dans le portail. Avant de partager les journaux, supprimez le nom d’utilisateur, les adresses, les chemins de clés et les secrets du projet.
$ ssh -vvv user@host
$ nc -vz host 22
$ scutil --dns
$ lsof -nP -iTCP -sTCP:LISTEN
SSH, l’accès distant via navigateur et la session de bureau graphique utilisent le même Mac physique dédié, mais leurs causes d’erreur diffèrent. Vérifiez d’abord la connexion sous-jacente, puis l’interaction de niveau supérieur.
Critère : la sortie détaillée doit indiquer à quelle étape s’arrêtent respectivement le DNS, l’établissement TCP, la vérification de l’hôte et l’authentification.
Critère : la stabilité de la liaison interactive prime sur la bande passante maximale ; les tâches en arrière-plan ne doivent pas dépendre d’une fenêtre de navigateur constamment ouverte.
Si un même projet fonctionne dans un terminal interactif mais échoue dans le Runner CI, la cause est souvent une différence de PATH, de droits, de variables d’environnement ou de compte d’exécution. Reproduisez d’abord la différence d’environnement avant de modifier la configuration du projet.
Exécutez xcode-select -p et xcodebuild -versionpour vérifier que le terminal interactif et le Runner utilisent le même ensemble d’outils. Si le projet impose une version, inscrivez la logique de sélection dans l’étape d’initialisation de la tâche.
Vérifiez d’abord la validité du certificat, la correspondance du profil de provisioning et les droits d’accès au trousseau. Ne vous limitez pas à la dernière ligne d’erreur de signature : recherchez le premier diagnostic de signature dans le journal du build.
Exécutez la tâche avec le fichier de verrouillage des dépendances du projet et vérifiez que Bundler, les plugins et les variables d’environnement proviennent du même répertoire de travail. Si le terminal interactif réussit mais que la tâche automatisée échoue, comparez le PATH et le répertoire de travail des deux environnements.
Vérifiez le compte d’exécution du Runner, le répertoire de travail, les répertoires de cache et les droits du répertoire temporaire. Les variables sensibles doivent être injectées par l’environnement de la tâche, jamais écrites dans le dépôt, les journaux ordinaires ou le corps d’un ticket.
Les données des projets sur un Mac physique dédié sont gérées par l’utilisateur. Définissez le répertoire avant de commencer, vérifiez les transferts, effectuez des sauvegardes indépendantes aux étapes clés et terminez la migration avant la fin de la location.
Séparez le code source, le cache des dépendances, les sorties de build et les fichiers temporaires. Les tâches CI doivent utiliser des chemins absolus explicites afin d’éviter que différents comptes d’exécution écrivent dans des emplacements imprévisibles.
Transférez les fichiers volumineux par lots et privilégiez les outils prenant en charge la reprise. Comparez le nombre de fichiers, leur taille et leurs sommes de contrôle avant et après le transfert ; ne vous fiez pas uniquement à la fin de la barre de progression.
L’unique copie présente sur l’appareil ne constitue pas une sauvegarde. Le code source doit être versionné et les artefacts essentiels ainsi que les résultats expérimentaux doivent être synchronisés vers un stockage indépendant géré par l’utilisateur.
N’attendez pas le dernier moment de la période de location pour exporter vos données. Prévoyez du temps pour le transfert, la vérification et les nouvelles tentatives, puis confirmez que la cible est lisible avant de supprimer les identifiants temporaires.
L’utilisateur est responsable des données du projet, des identifiants d’accès, des sauvegardes et de l’organisation de la migration avant la fin de la location. En cas de problème d’accès à l’appareil, envoyez rapidement un ticket depuis la commande concernée et indiquez les types de données non migrées ainsi que l’impact sur la tâche.
Les commandes sont disponibles à la journée, à la semaine, au mois ou au trimestre ; tous les frais sont réglés en dollars américains (USD). Les seuls moyens de paiement sont USDT-TRC20 et Visa / Mastercard / Amex (via Stripe). La passerelle effectivement disponible est indiquée dans le portail.
Pour une réparation courte, un archivage ponctuel ou une expérimentation temporaire, envisagez une formule à la journée. Pour des itérations continues, un Runner stable ou un projet de longue durée, comparez les formules à la semaine, au mois et au trimestre. Avant de commander, estimez la durée de la tâche, le temps de migration des données et l’organisation du relais entre équipes.
Ne créez pas plusieurs commandes identiques. Conservez le numéro de commande, l’heure du paiement, le montant et l’identifiant de transaction nécessaire renvoyé par le canal de paiement, puis envoyez un ticket depuis la commande concernée. Ne transmettez pas d’informations de paiement complètes ni de données sensibles du compte sans rapport avec le diagnostic.
Vérifiez les options supplémentaires, la période et la quantité dans la configuration de commande et le détail de la commande. La configuration Thunderbolt 5 en parallèle est calculée par appareil. Si les informations livrées diffèrent du détail de la commande, envoyez un ticket depuis cette commande avec une capture d’écran anonymisée.
Pour un problème d’exécution, envoyez de préférence un ticket depuis la commande concernée afin d’associer correctement l’appareil et la commande. Pour une demande générale, vous pouvez également écrire à support@deploymini.com.
Copiez le numéro de commande correspondant depuis le portail ; n’indiquez pas uniquement le nom donné à l’appareil.
Indiquez Singapour, Japon (Tokyo), Corée du Sud (Séoul), Hong Kong ou l’ouest des États-Unis.
Indiquez une plage horaire avec son fuseau et précisez si le problème persiste.
Listez les commandes, actions dans l’interface et résultats attendus dans l’ordre réel d’exécution.
Conservez la première erreur et son contexte avant et après, en supprimant les adresses, jetons et données métier.
Convient aux interruptions de connexion, anomalies matérielles, problèmes de livraison de commande et questions d’association avec la facturation. Ouvrez la commande dans le portail, puis créez un ticket.
Convient aux questions de configuration, de choix de formule, de sécurité et de confidentialité. Indiquez le type de problème dans l’objet ; si vous avez déjà une commande, ajoutez son numéro.
Recadrez les captures pour retirer les fenêtres inutiles et remplacez dans les journaux le nom d’utilisateur, l’adresse de l’hôte, les jetons, l’adresse du dépôt et les données du projet. Le diagnostic nécessite généralement uniquement le contexte de l’erreur et les identifiants indispensables.
Préciser le type de problème, son étendue et s’il est toujours en cours permet de limiter les demandes d’informations supplémentaires. Les quatre catégories ci-dessous utilisent le même point d’entrée, mais nécessitent des éléments de preuve différents.
Choix de configuration, couverture des nœuds, période de location, règles de paiement ou besoins durables de l’équipe.
Délai d’attente SSH, échec d’authentification, interruption de session du navigateur ou port cible inaccessible.
Erreurs persistantes liées au disque, à la mémoire, aux redémarrages ou à l’appareil, indépendantes d’un projet particulier.
Accès inhabituel, suspicion de fuite d’identifiants ou opérations système inattendues.
Ouvrir le ticket depuis la commande concernée permet de conserver l’association entre l’appareil, le nœud et la commande, et de réduire le délai de première vérification.
Pour une nouvelle tâche, suivez les étapes de démarrage afin de préparer les clés, le nœud et les versions des outils. Pour un problème en cours, envoyez un ticket depuis la commande concernée.