SSH
Erstverbindung
Prüfen Sie Schlüsselberechtigungen, Host-Fingerabdruck, Benutzernamen, Port und lokales Netzwerk. So erkennen Sie, ob der Fehler vor oder nach der Authentifizierung auftritt.
Verbindung prüfen
Verbindung, Build & Diagnose
Cloud-Mac-Probleme in prüfbare Schritte aufteilen
Wir beginnen nicht mit einem vagen „noch einmal versuchen“. Prüfen Sie zuerst den Verbindungszugang, danach Toolchain, Abhängigkeiten, Signaturdaten, Speicherplatz und Logs. Jeder Schritt nennt die erwartete Ausgabe – für iOS-Builds, macOS-Automatisierung und MLX-Experimente auf exklusiven physischen OakVPS-Rechnern.
Bei bestehenden Bestellungen melden Sie sich im Dashboard an und erstellen ein Ticket. Senden Sie niemals private Schlüssel, Passwörter von Signaturzertifikaten oder vollständige Zahlungsdaten auf öffentlichen Seiten.
Nach Aufgabe einsteigen
Prüfen, in welchem Abschnitt das Problem auftritt
Sechs Einstiege stehen bereit. Wenn ein Problem mehrere Phasen betrifft, beginnen Sie mit dem frühesten Fehler – leeren Sie nicht zuerst die gesamte Umgebung.
XCODE
Xcode-Build
Prüfen Sie Toolchain, Projektscheme, Abhängigkeitsstatus, Signaturdateien, freien Speicher und exportierbare Ergebnispakete.
Build-Befehle ansehen
FASTLANE
Automatisierte Pipeline
Unterscheiden Sie Ruby-Umgebung, Plugins, Lane-Parameter und Xcode-Fehler. Bewahren Sie das vollständige Log auf, statt nur die letzte Zeile zu kopieren.
Automatisierung prüfen
TRANSFER
Dateiübertragung
Verpacken Sie die Artefakte und erzeugen Sie eine Prüfsumme, bevor Sie das Archiv übertragen. Kopieren Sie keine noch beschriebenen Build-Verzeichnisse oder Abhängigkeits-Caches.
Übergabereihenfolge ansehen
SESSION
Remote-Entwicklungssitzung
Stellen Sie sicher, dass das lokale Netzwerk stabil ist, Aufgaben nach einer Sitzungsunterbrechung fortgesetzt werden können und Sie vor dem Verlassen des Geräts Sitzung und temporäre Dateien bereinigen.
Sitzungsgrenzen prüfen
MLX
MLX-Umgebung
Prüfen Sie Unified Memory, Modelldateien, isolierte Umgebungen und Versuchsprotokolle. Beurteilen Sie den Zustand nicht anhand nicht reproduzierbarer Geschwindigkeitswerte.
Versuchsumgebung prüfen
Basis der Erstverbindung
SSH-Verbindungsfehler nach dem Handshake prüfen
Speichern Sie zuerst den Originalfehler und ändern Sie danach jeweils nur eine Variable. Wer Benutzername, Port und Schlüssel gleichzeitig ändert, verliert die Ursache aus dem Blick.
Schlüsselberechtigungen
Führen Sie lokal aus: chmod 600 ~/.ssh/oakvps_key. Wenn der private Schlüssel für andere Benutzer lesbar ist, verweigert der SSH-Client seine Verwendung vor Beginn der Authentifizierung.
Host-Fingerabdruck
Vergleichen Sie beim ersten Verbindungsaufbau den im Terminal angezeigten Fingerabdruck mit den Verbindungsdaten im Dashboard, bevor Sie bestätigen. Ändern sich die Hostdaten, löschen Sie den alten Eintrag nicht einfach und überspringen die Prüfung.
Benutzername
Verwenden Sie den Systembenutzernamen aus den Verbindungsdaten der Bestellung. Setzen Sie weder Ihre E-Mail-Adresse noch den Benutzernamen Ihres lokalen Computers in den Remote-Befehl ein.
Port
Geben Sie den Port aus den Verbindungsdaten explizit an, zum Beispiel ssh -p 22 user@host. Timeouts treten meist vor der Authentifizierung auf; eine Berechtigungsverweigerung erfolgt typischerweise während der Authentifizierung.
Netzwerkfreigabe
Stellen Sie sicher, dass Unternehmensnetzwerk, VPN, lokale Firewall und Ausgangsregeln den Zielport zulassen. Testen Sie bei Bedarf in einem vertrauenswürdigen Netzwerk erneut, übertragen Sie Projektdaten aber nicht über ein unsicheres Netzwerk.
Erste Prüfung
Führen Sie nach erfolgreicher Anmeldung zuerst whoami, sw_vers und df -h aus. Protokollieren Sie Benutzer, Systemversion und freien Speicher, bevor Sie Projektdaten importieren.
Ausgabe zur Fehlersuche
Verbindungs-, Build- und Automatisierungsausgaben getrennt betrachten
Die letzte Terminalzeile ist meist nur das Ergebnis und nicht unbedingt die Ursache. Die folgenden drei Befehle prüfen getrennt Identität, Xcode-Build-Einstieg und fastlane-Lane-Status. Ersetzen Sie die Beispielparameter vor der Ausführung durch Ihre Verbindungsdaten, Ihr Workspace und Ihr Scheme.
- Verbindung erfolgreichRemote-Benutzername, Systemversion und Datenträgerinformationen werden ausgegeben.
- Build-Einstieg gültigWorkspace, Scheme und Zielplattform werden von Xcode korrekt erkannt.
- Automatisierung nachvollziehbarFehler von Bundler, Plugins und Lane behalten jeweils ihren vollständigen Kontext.
Verbindung und Umgebung prüfen
$ ssh -i ~/.ssh/oakvps_key -p 22 oak@203.0.113.10
$ whoami
oak
$ sw_vers -productVersion
15.x
$ df -h /Hinweis:Wenn der Befehl bereits den Remote-Benutzernamen ausgibt, sind Netzwerk und Authentifizierungsphase erfolgreich. Prüfen Sie bei späteren Problemen Systemberechtigungen oder die Projektumgebung.
Xcode-Build-Einstieg
$ 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.logHinweis:Prüfen Sie zuerst das Entwicklerverzeichnis und anschließend Workspace und Scheme. Bewahren Sie build.log auf, statt nur die abschließende Fehlerzusammenfassung zu kopieren.
fastlane-Ausgabe (Auszug)
$ 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 dependenciesHinweis:Wenn Lanes aufgelistet werden können, ist der Einstieg in die Ruby-Abhängigkeiten verfügbar. Suchen Sie bei einem späteren Fehler im Log nach dem ersten auftretenden Fehler, nicht nur nach dem Exit-Code.
Build-Fehlerdiagnose
Abhängigkeiten prüfen, nicht zuerst die gesamte Umgebung neu installieren
Versionen, Caches, Signaturen, Speicherplatz und Logs beeinflussen sich gegenseitig. Die folgende Reihenfolge vermeidet unnötige Änderungen und ermöglicht der nächsten Person, denselben Fehler zu reproduzieren.
| Reihenfolge | Prüfobjekt | Ausführen oder protokollieren | Kriterium |
|---|---|---|---|
| 01 | Xcode-Version | xcodebuild -version und xcode-select -p |
Toolchain-Anforderung des Projekts und aktives Verzeichnis stimmen überein; CLI und grafische Oberfläche verweisen nicht auf unterschiedliche Versionen. |
| 02 | Abhängigkeits-Cache | Lock-Datei zuerst protokollieren, danach Status von Swift Package, CocoaPods oder projektspezifischem Cache prüfen. | Die Lock-Datei wurde nicht unbeabsichtigt geändert. Löschen Sie nur den zum aktuellen Fehler gehörenden Cache, nicht alle weiterhin nutzbaren Abhängigkeiten. |
| 03 | Signaturdaten | Ziel, Bundle-ID, Zertifikatsgültigkeit und Zuordnung zum Provisioning Profile prüfen. | Die Daten passen zum aktuellen Build-Ziel. Passwörter und vertrauliche Inhalte gelangen nicht in Logs, Repository oder Ticketanhänge. |
| 04 | Speicherplatz | df -h, Projektverzeichnisgröße und DerivedData-Größe. |
Für Build-Verzeichnis, Abhängigkeiten, Archive und temporäre Dateien ist ausreichend Speicher vorhanden; ungewöhnlich wachsende Verzeichnisse sind separat identifiziert. |
| 05 | Vollständiges Log | Verwenden Sie tee zur gleichzeitigen Anzeige und Speicherung der Ausgabe. Protokollieren Sie Befehl, Zeit und Exit-Code. |
Das Log enthält ersten Fehler, Kontext und finalen Status und kann von einer anderen Person mit demselben Befehl reproduziert werden. |
Lock-Datei vergleichen, dann Cache leeren
Wenn sich die Abhängigkeitsauflösung plötzlich ändert, prüfen Sie zunächst Unterschiede der Lock-Datei vor und nach dem Commit, Paketquellen und Netzwerkergebnis. Löschen Sie den betreffenden Bereich erst nach bestätigter Cache-Beschädigung, damit ein reproduzierbarer Fehler nicht zum einmaligen Zustand wird.
Fehlende Daten von falscher Zuordnung unterscheiden
Die Ursache kann ein nicht verfügbares Zertifikat, ein nicht zur Bundle-ID passendes Profil oder ein falsches Build-Ziel sein. Protokollieren Sie Fehlercode und Zielname, aber niemals Zertifikatspasswort, privaten Schlüssel oder vollständige Signaturdaten im Ticket.
Vollständigen Kontext des ersten Fehlers bewahren
Wiederholte Ausführung kann Caches und temporäre Dateien verändern. Speichern Sie nach dem ersten Fehler zunächst Logs, Befehle, Workspace-Status und Speicherinformationen. Testen Sie danach mit nur einer Änderung, um ihre Wirkung zu beurteilen.
Sitzung und Artefaktübergabe
Remote-Sitzungen und Dateiübergaben getrennt wiederherstellbar machen
Das Remote-Fenster ist nur der Bedienzugang und darf nicht der einzige Speicherort des Aufgabenstatus sein. Befehle, Logs, Artefakte und Prüfsummen gehören in klar definierte Verzeichnisse.
Remote-Sitzung
Vor dem Verbinden und Verlassen jeweils den Status prüfen
- 01Vorbereitung vor der Verbindung
Prüfen Sie lokales Netzwerk, Host-Fingerabdruck, Zielbenutzer und Herkunft der Projektdaten. Importieren Sie sensible Dateien nur, wenn die Aufgabe sie benötigt.
- 02Lange Aufgaben außerhalb des Fensters
Führen Sie Build oder Experiment in einer wiederherstellbaren Sitzungsverwaltung aus und schreiben Sie die Standardausgabe gleichzeitig in eine Logdatei.
- 03Beim Verlassen abmelden
Vergewissern Sie sich, dass Dateien gespeichert und Aufgabenstatus protokolliert sind. Beenden Sie danach grafische Oberfläche oder SSH-Sitzung, ohne ungespeicherte Änderungen im Fenster zu lassen.
- 04Berechtigungen entziehen
Entziehen Sie nach dem Ausscheiden von Teammitgliedern oder Abschluss der Aufgabe nicht mehr benötigte Schlüssel und Zugriffsrechte und prüfen Sie gemeinsame Verzeichnisse.
Dateiübergabe
Artefakte, Logs und vertrauliche Daten getrennt behandeln
- 01Schreibvorgang beenden
Vergewissern Sie sich, dass der Build abgeschlossen ist, und archivieren Sie erst dann die Artefakte. Übertragen Sie keine noch erzeugten Verzeichnisse oder Datenbankdateien.
- 02Manifest erstellen
Notieren Sie Dateinamen, Build-Version, Umgebungsversion, Erstellungsbefehl und Prüfsumme, damit der Empfänger die Vollständigkeit prüfen kann.
- 03Download prüfen
Entpacken Sie lokal und prüfen Sie wichtige Dateien. Stellen Sie sicher, dass das Archiv kein leeres Verzeichnis ist und keine erforderlichen Logs fehlen.
- 04Vertrauliche Dateien bereinigen
Löschen Sie nach Teamrichtlinie temporäre Schlüssel, Token, Signaturdaten und nicht mehr benötigte Modellkopien. Bewahren Sie öffentlich teilbare Build-Aufzeichnungen auf.
MLX-Experimente prüfen
Modell, Umgebung und Speicherspielraum zuerst dokumentieren
MLX nutzt den Unified Memory von Apple Silicon. Modelldateien, Laufzeitverbrauch, Kontextlänge und Zwischenergebnisse beeinflussen gemeinsam den verfügbaren Speicher. Bewerten Sie die Umgebung daher nicht nur anhand der Modellgröße oder einer einzelnen Laufzeit.
Alle drei Stufen nutzen exklusive physische Rechner: Die Basisstufe bietet M4, 16 GB RAM und 256 GB Speicher; die mittlere Stufe M4, 24 GB RAM und 512 GB Speicher; die Speicherstufe M4 Pro, 64 GB RAM und 2 TB Speicher. Wählen Sie anhand des gemessenen Verbrauchs von Modell, Datensatz und parallelen Aufgaben.
Experimentierumgebung isolieren
Legen Sie für jedes Projekt Python-Umgebung und Abhängigkeitsversionen fest und speichern Sie eine reproduzierbare Abhängigkeitsliste. Installieren Sie nicht mehrere Experimentversionen in der Systemumgebung.
Größe der Modelldateien prüfen
Dokumentieren Sie Größe von Downloadpaket, entpackten Dateien, Cache und Ausgabeordner getrennt. Lassen Sie Platz für temporäre Dateien, damit das Experiment nicht wegen vollem Speicher abbricht.
Speicherstufe wählen
Protokollieren Sie Spitzenverbrauch anhand der Aktivitätsanzeige oder per Kommandozeile. Bei anhaltendem Speicherdruck reduzieren Sie Parallelität, verkleinern die Aufgabe oder passen die Konfiguration an, statt sie nur erneut auszuführen.
Experiment-Logs aufbewahren
Notieren Sie Code- und Abhängigkeitsversion, Modellkennung, Parameter, Eingabezusammenfassung, Ausgabeort und Fehler. So lässt sich der nächste Lauf unter denselben Bedingungen reproduzieren.
Vor dem Supportticket
Ticket als reproduzierbare Aufzeichnung strukturieren
Das Supportteam muss wissen, welche Bestellung, welcher Knoten, welcher Schritt und welcher Zeitraum betroffen sind. Je konkreter die Angaben, desto schneller beginnt die Diagnose.
Bestellkennung
Geben Sie die im Dashboard sichtbare Bestellkennung an. Senden Sie keine Zahlungsbelege oder vollständigen Zahlungsdaten.
Erforderlich
Physischer Knoten
Nennen Sie den für die Bestellung verwendeten Knoten und den aktuellen Verbindungszugang, damit Netzwerkpfad und Umgebungsbereich unterschieden werden können.
Erforderlich
Zeitpunkt
Verwenden Sie eine Zeitzone und geben Sie an, ob das Problem dauerhaft, sporadisch oder nur bei einer Aufgabe auftrat.
Erforderlich
Reproduktionsschritte
Beginnen Sie im Normalzustand und listen Sie Befehle, Parameter, erwartetes und tatsächliches Ergebnis der Reihe nach auf. Lassen Sie keine Zwischenschritte aus.
Erforderlich
Bereinigte Logs
Fügen Sie vollständigen Fehlerkontext und Exit-Code bei. Entfernen Sie private Schlüssel, Token, Zertifikatspasswörter, Repository-Zugangsdaten und vertrauliche Projektdaten.
EmpfohlenSie suchen einen Cloud-Mac für den sofortigen Einsatz?
Wählen Sie Oak M4, Oak M4 Plus oder Oak M4 Pro und mieten Sie einen exklusiven physischen Rechner passend zur Aufgabedauer. Nach der Bestellung finden Sie Bestellung, Verbindungsdaten und Supportticket im Dashboard.