Eine Miete entspricht einem dedizierten physischen Apple-Silicon-Knoten. Bei Verbindungsproblemen prüfen Sie zuerst den Konsolenstatus, danach lokales Netzwerk, Authentifizierung, Systemdienste und Prozesse. Installieren Sie die Toolchain nicht wiederholt, solange wichtige Informationen fehlen.
Kopieren Sie Adressen und Zugangsdaten nicht aus Chatverläufen oder alten Dokumenten. Maßgeblich sind Knotenstatus, Verbindungsadresse, Kontoinformationen und Zugriffskontrollen, wie sie für die aktuelle Bestellung in der Konsole angezeigt werden.
Prüfen Sie zuerst, ob der zur Bestellung gehörende physische Knoten verbindungsbereit ist. Wird der Status noch aktualisiert, bewahren Sie die Bestell-ID auf und warten Sie auf die nächste Information der Konsole. Erstellen Sie nicht wiederholt identische Bestellungen.
Prüfen Sie Hostadresse und Port Zeichen für Zeichen. Achten Sie auf Leerzeichen, Vollbreitzeichen und Informationen eines alten Knotens. Bei Unternehmensnetzwerken muss außerdem die Ausgangsrichtlinie den Zielport zulassen.
Verwenden Sie die der Bestellung zugewiesenen Kontodaten und beschränken Sie die Leserechte des privaten Schlüssels auf den aktuellen Benutzer. Passwörter, private Schlüssel und Signaturzertifikate gehören weder in normale E-Mail-Texte noch in öffentliche Repositories.
Für Kommandozeile, Codesynchronisierung und Automatisierung bevorzugt SSH verwenden; für die grafische macOS-Oberfläche die in der Bestellung angegebene Remote-Verbindung nutzen.
SSH-Fehler treten in unterschiedlichen Phasen auf. Ein Verbindungs-Timeout deutet meist auf den Netzwerkpfad hin; bei einem geänderten Hostschlüssel muss zuerst die Knotenidentität geprüft werden. Bei Authentifizierungsfehlern prüfen Sie Benutzername, Schlüsselformat und Dateiberechtigungen.
Bewahren Sie den privaten Schlüssel in einem kontrollierten Verzeichnis auf, nicht im Projekt-Repository. Bei zu weit gefassten Berechtigungen verweigert der SSH-Client die Verwendung der Datei.
chmod 600 ~/.ssh/mangovm_node
ssh -i ~/.ssh/mangovm_node -p <PORT> <USER>@<HOST>Der bei der ersten Verbindung angezeigte Fingerabdruck muss mit den Angaben in der Konsole übereinstimmen. Wenn Sie ihn nicht bestätigen können, brechen Sie die Verbindung ab und erstellen Sie ein Ticket. Ignorieren Sie die Warnung nicht einfach.
Builds, Archivierung und Abhängigkeitsinstallationen sollten von Runner, launchd oder einem zuverlässigen Sitzungsmanager ausgeführt werden. Hängen Sie wichtige Aufgaben nicht ausschließlich an eine einzelne SSH-Sitzung auf Ihrem Laptop.
Prüfen Sie nacheinander Benutzername, Pfad des privaten Schlüssels, Dateiberechtigungen und die Zuordnung des Schlüssels zum aktuellen Knoten. Wenn das Netzwerk steht, aber die Authentifizierung scheitert, muss der Knoten nicht zuerst neu gestartet werden.
Ticket mit Authentifizierungszusammenfassung einreichenTesten Sie zunächst über ein anderes vertrauenswürdiges Netzwerk. Notieren Sie Zielport, öffentliche Ausgangsadresse des Clients sowie Start- und Endzeit. Ein Timeout hängt nicht vom Schlüsselinhalt ab; wechseln Sie nicht wiederholt den Schlüssel, um ein Netzwerkproblem zu verdecken.
Diagnosebaum weiterverfolgenEin fester physischer Knoten eignet sich für stabile Toolchains und Projekt-Caches. Stabilität entsteht durch klare Parallelitätsgrenzen, getrennte Arbeitsverzeichnisse, nachvollziehbare Logs und Bereinigung nach Abschluss – nicht durch immer mehr Hintergrundprozesse.
Erstellen Sie für jedes Projekt oder jede Organisation einen eigenen Runner und kennzeichnen Sie Chip, Toolchain und Zweck eindeutig. Registrierungstoken dürfen nur in kontrollierten Umgebungen verwendet werden und müssen danach aus temporären Befehlen und Logs entfernt werden.
Große Xcode-Builds, Simulator-Tests und Archivierungen können gleichzeitig CPU, Arbeitsspeicher und Speicherplatz beanspruchen. Beginnen Sie mit einem parallelen Auftrag, beobachten Sie die Spitzenwerte und passen Sie die Einstellung anhand echter Logs schrittweise an.
Signaturzertifikate, Schlüssel und Zugriffstoken müssen über kontrollierte Variablen oder lokale Berechtigungen isoliert werden. Speichern Sie sie nicht in Repositorys, Build-Artefakten oder herunterladbaren Logs. Bereinigen Sie temporäre Dateien nach Abschluss.
Dokumentieren Sie Commit, Xcode-Version, SDK, gesperrte Abhängigkeiten, Startzeit, Exit-Code und wichtige Fehler. Fügen Sie dem Ticket nur bereinigte Ausschnitte und die zugehörige Aufgaben-ID bei.
MangoVM-Knoten laufen dauerhaft 365 Tage im Jahr. Upgrades von macOS und Entwicklungstools führen Sie in einem von Ihnen gewählten geschäftlich ruhigen Zeitraum durch. Sichern Sie vor Änderungen die Daten, prüfen Sie die Kompatibilität und bereiten Sie Wiederherstellungsunterlagen vor.
Exportieren Sie Projekte, gesperrte Abhängigkeiten, Build-Konfigurationen, wichtige Logs und zu erhaltende lokale Daten zum selben Zeitpunkt. Dokumentieren Sie Umfang und Prüfergebnis des Backups. Das Backup muss vom lokalen Knotenspeicher getrennt sein.
Prüfen Sie macOS-Zielversion, Xcode, SDK, Paketmanager, Runner und Projektskripte einzeln. Führen Sie Kompilierung, Tests, Archivierung und Upload-Vorprüfung zunächst mit unkritischen Aufgaben durch.
Stoppen Sie neue Builds in der Warteschlange und stellen Sie sicher, dass keine Archivierung, Cache-Bereinigung oder Abhängigkeitsaktualisierung auf den Speicher schreibt. Dokumentieren Sie Startzeit, ausführende Person und Version vor dem Upgrade.
Kann ein wichtiges Projekt nicht kompiliert werden, lässt sich der Runner nicht registrieren oder sind zentrale Abhängigkeiten inkompatibel, beenden Sie weitere Änderungen. Bewahren Sie die Logs auf und stellen Sie Daten und Toolchain nach den zuvor dokumentierten Schritten wieder her.
| Prüfobjekt | Vor dem Upgrade dokumentieren | Nach dem Upgrade validieren | Bei Fehlern aufbewahren |
|---|---|---|---|
| Xcode und SDK | Aktuelle Version, Projektziel, Pfad der Kommandozeilentools | Kompilierung, Unit-Tests, Archivierung | Versionsausgabe und erstes Fehlerprotokoll |
| Abhängigkeitsverwaltung | Sperrdatei, Mirror-Einstellungen, Cache-Umfang | Abhängigkeiten in ein leeres Verzeichnis wiederherstellen | Sperrdatei und Ausschnitt des Auflösungsfehlers |
| Runner-Dienst | Tags, Parallelität, Arbeitsverzeichnis, Startmethode | Nach dem Neustart automatisch online gehen und Aufgaben übernehmen | Dienststatus und Exit-Code der Aufgabe |
| Projektdaten | Backup-Umfang, Exportort, Prüfergebnis | Stichprobenzugriff und Wiederherstellungstest | Fehlende Pfade und letzte funktionierende Version |
Bei Problemen mit Zusatzspeicher oder einem Thunderbolt-5-Verbund prüfen Sie zuerst die Optionen der Bestellung und anschließend Systemerkennung, Mount-Pfad, Verzeichnisberechtigungen und Aufgabenkonfiguration. Preise und Laufzeiten entsprechen den offiziellen Angaben auf der Tarifseite.
Prüfen Sie, ob die Bestellung die gewünschte Zusatzoption enthält, ob der Abrechnungszeitraum übereinstimmt und ob die Konsole die entsprechende Konfiguration zurückgegeben hat. Beurteilen Sie den Status nicht allein anhand eines alten Pfads im Projektskript.
Stellen Sie sicher, dass das System das gewünschte Volume erkennt und der Build-Benutzer die erforderlichen Lese- und Schreibrechte für das Arbeitsverzeichnis besitzt. Öffnen Sie nicht für die gesamte Festplatte übermäßig weit gefasste Berechtigungen, um ein Problem in einem einzelnen Verzeichnis zu umgehen.
Prüfen Sie Zusatzoption, Kabelverbindung und Aufgabenverteilung für jeden Knoten einzeln. Validieren Sie Lese-/Schreibzugriff oder die Zusammenarbeit zwischen Knoten zunächst mit einer einzigen reproduzierbaren Aufgabe, bevor Sie die Stapelwarteschlange wieder aufnehmen.
Auf der Tarifseite sind Tages-, Wochen-, Monats- und Quartalspreise für +1TB SSD, +2TB SSD und den Thunderbolt-5-Verbund aufgeführt. Bei Abrechnungsfragen geben Sie bitte zusätzlich Bestell-ID und gewählten Zeitraum an.
Wenn Sie Ebenen überspringen, vermischen sich die Symptome. Arbeiten Sie die folgende Reihenfolge ab und dokumentieren Sie Zeit, Ergebnis und Änderungen jedes Schritts. Gehen Sie erst weiter, wenn die vorherige Ebene fehlerfrei ist.
Prüfen Sie Knotenstatus, Bestell-ID, Region und Vollständigkeit der Verbindungsdaten. Wird die Information noch aktualisiert, beenden Sie lokale Authentifizierungsversuche und dokumentieren Sie den aktuellen Status.
Testen Sie über ein anderes vertrauenswürdiges Netzwerk, um Unterschiede durch Unternehmensausgang, Firewall, Proxy oder lokales VPN auszuschließen. Dokumentieren Sie Testnetzwerk und Zeitpunkt.
Prüfen Sie Benutzername, Schlüsselpfad, Dateiberechtigungen und Hostschlüssel. Übernehmen Sie known_hosts-Einträge oder Automatisierungsvariablen eines alten Knotens nicht direkt für eine neue Bestellung.
Prüfen Sie SSH, Runner, Build-Agent und abhängige Projektdienste. Dokumentieren Sie Dienststatus, letzten Exit-Code und letzte Konfigurationsänderung. Starten Sie Dienste nicht wiederholt ohne Protokollierung neu.
Prüfen Sie Parallelitätswarteschlange, Speicherplatz, Berechtigungen des Arbeitsverzeichnisses, Abhängigkeitssperren und Aufgaben-Timeouts. Dokumentieren Sie den ersten Fehlerschritt getrennt von späteren Folgefehlern.
Je genauer die Informationen zur Fehlerstufe passen, desto leichter kann das Supportteam den Fehler reproduzieren. Übermitteln Sie über alle Kanäle nur notwendige Informationen; sensible Materialien dürfen erst nach Bestätigung des sicheren Übermittlungswegs durch das Supportteam gesendet werden.
Beschreiben Sie Zielaufgabe, Parallelitätsumfang, bevorzugte Region, geplante Mietdauer und Speicherbedarf. Bei einer bestehenden Bestellung geben Sie die Bestell-ID an, aber keine Zugangsdaten.
Geben Sie Bestell-ID, Region, Verbindungsmethode, Zeitpunkt, Clientnetzwerk, Fehlerzusammenfassung sowie die Prüfergebnisse der ersten fünf Ebenen des Diagnosebaums an. Schreiben Sie nicht nur „Verbindung nicht möglich“.
Stoppen Sie verdächtige Aufgaben, widerrufen Sie möglicherweise offengelegte temporäre Zugriffe und bewahren Sie Logs und Zeitachse auf. Übermitteln Sie Bestell-ID, Entdeckungsmethode, Auswirkungsumfang und bereits ergriffene Maßnahmen. Senden Sie keine weiterhin nutzbaren Schlüssel.
Benötigen Sie einen neuen Knoten, starten Sie direkt den Bestellvorgang. Bei Problemen mit einer bestehenden Bestellung erstellen Sie in der Konsole ein Ticket mit Reproduktionsschritten und bereinigten Logs.