Verbinden · Konfigurieren · Fehler beheben

Erst das Problem finden, dann weiterbauen

Hier finden Sie Anleitungen für Ihren Cloud-Mac. Bei der ersten Verbindung helfen Ihnen die vier Karten unten. Wenn bei einer bestehenden Instanz ein Problem auftritt, suchen Sie nach dem Symptom oder springen Sie direkt zur Fehlerbehebung.

Nach der ersten Bereitstellung

Verbindung und Zugriffsrechte zuerst prüfen

MacFTP stellt dedizierte physische Apple-Silicon-Macs mit nativem macOS bereit – keine virtuellen Maschinen. Verwenden Sie für die folgenden Schritte die tatsächliche IP-Adresse, den Benutzernamen und die Verbindungsdaten aus den Instanzdetails in der Konsole. Die Bestellnummer ist nicht Ihr Anmeldename.

Per SSH anmelden

Öffnen Sie ein lokales Terminal und ersetzen Sie Benutzername, IP-Adresse und Port im Verbindungsbefehl durch die Angaben aus den Instanzdetails. Prüfen Sie beim ersten Verbindungsaufbau den Host-Fingerabdruck, bevor Sie ihm vertrauen.

ssh -p PORT USER@NODE_IP

Fehlertyp prüfen: Bei einer Zeitüberschreitung zuerst das Netzwerk prüfen. Bei „Connection refused“ Port und Instanzstatus prüfen. Bei „Permission denied“ Benutzer und Authentifizierungsmethode überprüfen – raten Sie nicht wiederholt Passwörter.

VNC / Bildschirmfreigabe

Die verfügbaren Verbindungsdaten für die grafische Oberfläche finden Sie in den Instanzdetails der Konsole. Tragen Sie im Client Adresse, Port und Zugangsdaten wie in den Bereitstellungsinformationen angegeben ein. Verwenden Sie nicht ungeprüft das SSH-Passwort für die grafische Sitzung oder umgekehrt.

Bei einem schwarzen Bildschirm trennen Sie die Verbindung und verbinden Sie sich erneut. Achten Sie darauf, nicht versehentlich eine alte Sitzung erneut zu öffnen. Wenn SSH funktioniert, sichern Sie zuerst die Build-Protokolle und prüfen Sie, ob das System noch arbeitet. Starten Sie nicht sofort die ganze Maschine neu.

Der Einstieg zur grafischen Verbindung im Browser ist nur in den Instanzdetails nach der Anmeldung verfügbar. Auf der öffentlich zugänglichen Hilfeseite werden keine Zugangsdaten angezeigt.

Passwort und Schlüssel

Ändern Sie nach der ersten Anmeldung mit dem Befehl passwd das Passwort des aktuellen Benutzers. Erstellen Sie lokal einen SSH-Schlüssel und fügen Sie nur den öffentlichen Schlüssel auf dem Remote-System zu ~/.ssh/authorized_keys hinzu. Der private Schlüssel bleibt lokal.

~/.ssh Setzen Sie die Berechtigungen des Verzeichnisses auf 700, authorized_keys auf 600. Lassen Sie die aktuelle Verbindung geöffnet und prüfen Sie in einem zweiten Terminal, ob die Anmeldung mit dem Schlüssel funktioniert.

Schließen Sie die bestehende Sitzung nicht und deaktivieren Sie keine vorhandene Authentifizierungsmethode, bevor die Prüfung abgeschlossen ist. Passwörter, private Schlüssel und Wiederherstellungsdaten gehören nicht in ein Support-Ticket.

Xcode und Befehlszeilen-Tools

Führen Sie zuerst xcode-select -p und xcodebuild -versionaus, um die aktuelle Umgebung zu prüfen. Wenn Sie eine grafische Oberfläche benötigen, suchen Sie Xcode unter „Applications“ in einer Remote-Sitzung.

Wenn Sie nur die Befehlszeilen-Tools verwenden, können Sie xcode-select --installausführen. Für iOS-Archive wird weiterhin die vollständige Xcode-Installation benötigt. Starten Sie eine neu installierte Xcode-Version zunächst einmal und richten Sie die erforderlichen Komponenten ein, bevor Sie sie in CI verwenden.

Wenn mehrere Versionen installiert sind, wählen Sie anhand des tatsächlichen Verzeichnisses. Benennen Sie nicht nur die App um, während der Runner weiterhin das alte Entwicklerverzeichnis verwendet.

Vom lokalen Rechner in die Cloud

Die Migration in drei Schritten – mit Abnahmekriterien

Führen Sie zuerst einen einzelnen Build mit demselben Commit erfolgreich aus und richten Sie erst danach automatisierte Jobs ein. Die Zeitangaben dienen der Planung und sind keine Lieferzusage. Repository-Größe, Netzwerk, Downloads von Abhängigkeiten und die Vorbereitung der Signierung beeinflussen die tatsächliche Dauer.

01 / Daten

Quellcode synchronisieren, Build-Cache nicht übernehmen

Planen Sie 15–45 Minuten ein; große Repositories mit vielen Ressourcen können länger dauern.

Checken Sie möglichst einen festgelegten Commit aus dem Versionsverwaltungssystem aus. Noch nicht eingecheckte Dateien können Sie per SFTP oder rsync übertragen. Schließen Sie DerivedData, den Projektordner build und lokale Protokolle aus, damit keine veralteten Pfade oder nicht mehr gültigen Caches auf dem neuen Rechner landen.

Prüfen Sie die Dateiliste zuerst mit dry-run und starten Sie anschließend die eigentliche Synchronisierung. Ersetzen Sie USER und NODE_IP im Beispiel durch die Angaben aus der Instanzbereitstellung. Einen eigenen SSH-Port müssen Sie zusätzlich konfigurieren.

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

Abnahmekriterien: Auf beiden Seiten derselbe Commit, alle benötigten Ressourcendateien vorhanden und keine vertraulichen Konfigurationen im Repository.

02 / Toolchain

Abhängigkeiten und Signierungsumgebung neu einrichten

Planen Sie 30–90 Minuten ein. Der erste Download kann länger dauern.

Notieren Sie die Versionen von Xcode, SDK, Homebrew und den Skriptabhängigkeiten auf Ihrem lokalen Rechner. Prüfen Sie zunächst mit brew --version ob Homebrew bereits installiert ist. Wenn das Projekt eine Brewfile enthält, stellen Sie die Abhängigkeiten anschließend anhand dieser Datei wieder her.

Übertragen Sie die für die Signierung benötigten p12-Dateien und Provisioning-Profile über eine verschlüsselte Verbindung. Importieren Sie das Zertifikat in einen eigenen Schlüsselbund und legen Sie das Profil im Verzeichnis des Build-Benutzers ab. Passwörter gehören weder ins Repository noch in Build-Protokolle.

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

Abnahmekriterien: Das SDK erfüllt die Projektanforderungen, die Signierungsidentität ist gültig und ein manuell gestartetes Archive wird vollständig erstellt.

03 / CI einrichten

Runner registrieren und danach automatische Auslöser aktivieren

Planen Sie 20–60 Minuten ein, ohne die Testdauer des Projekts.

Installieren Sie den selbst gehosteten GitHub-Actions-Runner oder den GitLab-Runner mit den Registrierungsbefehlen Ihrer Codeplattform. Das Registrierungstoken wird nur bei der Einrichtung benötigt. Speichern Sie kein Maschinenpasswort im Workflow.

Prüfen Sie die Labels self-hosted, macOS und ARM64 . Starten Sie zuerst manuell einen Build mit einem festgelegten Commit. Prüfen Sie Arbeitsverzeichnis, Pfad der Build-Artefakte und Signierungsberechtigungen, bevor Sie automatische Builds für Branches aktivieren.

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

Abnahmekriterien: Der Runner ist online, der richtige Commit wird verwendet, das Archiv lässt sich abrufen und die Protokolle enthalten keine Zugangsdaten.

Wenn mehrere Jobs auf demselben physischen Knoten laufen, teilen sie sich weiterhin CPU, Unified Memory und SSD. Begrenzen Sie zuerst die Parallelität und erhöhen Sie sie schrittweise. So verwechseln Sie Konkurrenz um Ressourcen nicht mit einem Problem des Knotens.

Schritt für Schritt ausführen

Häufige Befehle: Voraussetzungen prüfen, dann kopieren

Verzeichnis- und Dateinamen in den Befehlsbeispielen sind Platzhalter. Ersetzen Sie sie vor der Ausführung durch tatsächlich vorhandene Pfade auf dem Rechner. Für Befehle mit sudo sind Administratorrechte erforderlich. Fügen Sie keine Befehle mit Passwörtern in öffentliche Protokolle ein.

Xcode-Entwicklerverzeichnis auswählen

Dieses Beispiel gilt, wenn /Applications/Xcode.app bereits vorhanden ist. Prüfen Sie bei mehreren Versionen zuerst den App-Pfad und kontrollieren Sie nach dem Wechsel Version und SDK. Wenn nur der aktuelle Job eine andere Version verwenden soll, können Sie in diesem Job DEVELOPER_DIR festlegen.

Wechseln und prüfen
sudo xcode-select --switch /Applications/Xcode.app/Contents/Developer
xcode-select -p
xcodebuild -version
xcodebuild -showsdks

p12 in den Build-Schlüsselbund importieren

Erstellen Sie zunächst einen eigenen Schlüsselbund namens build.keychain-db und entsperren Sie ihn in der Benutzersitzung, in der der Job ausgeführt wird. Geben Sie beim Import das p12-Passwort entsprechend der Systemaufforderung ein. Dass das Zertifikat sichtbar ist, bedeutet nicht automatisch, dass die Zugriffsrechte auf den privaten Schlüssel für CI ausreichen.

Import und Identität prüfen
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"

Runner mit launchd verwalten

Die folgenden Schritte gelten für ein bereits registriertes GitHub-Actions-Runner-Verzeichnis, das svc.sh enthält. Das Dienstskript installiert und startet den Runner; die Verwaltung im Hintergrund übernimmt launchd. Für GitLab Runner verwenden Sie die zugehörigen Dienstbefehle und nicht dieses Skript.

Im Runner-Verzeichnis ausführen
./svc.sh install
./svc.sh start
./svc.sh status
launchctl list | grep -i runner

Ein Eintrag in launchd bestätigt nur, dass der Dienst registriert wurde. Prüfen Sie zusätzlich auf Ihrer Codeplattform, ob der Runner online ist, und starten Sie einen Test-Build. Für Jobs, die eine grafische Oberfläche oder eine Interaktion mit dem Schlüsselbund benötigen, müssen Sie auch den Status der Benutzersitzung prüfen.

Bestellung und Laufzeit

Ablaufdatum und Zahlungsstatus getrennt prüfen

Der Dienst wird im Voraus für Tage, Wochen, Monate oder Quartale bezahlt. Der Gesamtbetrag für die gewählte Laufzeit wird auf einmal abgerechnet. Kontostatus, Zahlungsstatus und Instanzstatus sind voneinander unabhängig. Halten Sie bei einer Anfrage sowohl Bestellnummer als auch Instanznummer bereit.

Wie verlängere ich und wie stelle ich sicher, dass meine Daten erhalten bleiben?

Melden Sie sich in der Konsole an und prüfen Sie das Ablaufdatum sowie die Verlängerungsoption bei der Bestellung des Abonnements oder der Instanz. Verlängern Sie das bestehende Abonnement und kontrollieren Sie, ob sich die Laufzeit verlängert hat. Eine neue Bestellung für eine andere Instanz verlängert nicht die bestehende Instanz. Wenn sich das Ablaufdatum nach der Zahlung nicht ändert, bewahren Sie den Zahlungsbeleg auf und erstellen Sie ein Support-Ticket. Sichern Sie wichtige Daten zusätzlich selbst.

Erhalte ich eine Erinnerung vor Ablauf und welches Datum ist maßgeblich?

Maßgeblich ist das Ablaufdatum der Bestellung in der Konsole. Beachten Sie auch die dort angegebene Zeitzone. Halten Sie die E-Mail-Adresse Ihres Kontos aktuell und prüfen Sie Posteingang sowie Spam-Ordner. Ob eine E-Mail eingetroffen ist, ist kein verlässlicher alleiniger Nachweis für die Laufzeit. Richten Sie zur Sicherheit eine eigene Erinnerung im Teamkalender ein und verlängern Sie vor Ablauf oder übertragen Sie Code, Zertifikate und Build-Artefakte.

Welche Zahlungsmethoden und Währungen gibt es und wie prüfe ich eine Transaktion?

Unterstützt werden ausschließlich USDT-TRC20 sowie Visa / Mastercard / Amex über Stripe. Abgerechnet wird immer in US-Dollar (USD). Welche Zahlungsoptionen tatsächlich verfügbar sind, hängt von der Rückmeldung des Zahlungsdienstes ab. Prüfen Sie bei Zahlungen auf der Blockchain Netzwerk, Betrag und Angaben auf der Zahlungsseite. Bei Kartenzahlungen ist das Ergebnis in der Bestellung maßgeblich. Geben Sie bei Rückfragen die Bestellnummer oder den Transaktions-Hash an – niemals die vollständige Kartennummer, einen Verifizierungscode oder den privaten Schlüssel Ihrer Wallet.

Wo kann ich Probleme mit einer Zahlung, Rückerstattungen und Belege klären?

Prüfen Sie zuerst in der Konsole die Rechnung, Zahlungseinträge und verfügbare Belege. Bedingungen, Umfang und weitere Regeln für Rückerstattungen finden Sie in den Nutzungsbedingungen. Löschen Sie nicht einfach lokale Verbindungsdaten oder stellen Sie die Nutzung der Maschine ein, um eine Rückerstattung zu beantragen. Bei einer möglichen Doppelabbuchung geben Sie die betroffenen Bestellungen und Transaktionsreferenzen an und lassen Sie den Fall über ein Support-Ticket in der Konsole prüfen.

Zuerst den Ist-Zustand sichern

Fehler selbst beheben: vom kleinsten zum größten Bereich

Stellen Sie zunächst fest, ob nur ein Client, eine einzelne Sitzung oder der gesamte Knoten betroffen ist. Notieren Sie die ursprüngliche Fehlermeldung und den Zeitpunkt. Arbeiten Sie die Schritte nacheinander ab und ändern Sie nicht gleichzeitig Netzwerk, Passwort und Neustartoptionen – sonst lässt sich die Ursache später schwerer nachvollziehen.

Netzwerk und Verbindungsziel

Prüfen Sie IP-Adresse, Port und Benutzernamen noch einmal anhand der Instanzdetails. Versuchen Sie es über ein anderes lokales Netzwerk und prüfen Sie lokalen Proxy, Firewall sowie die Richtlinien für den Unternehmenszugang. Ein fehlgeschlagener ICMP-Ping beweist nicht, dass SSH nicht erreichbar ist. Entscheidend ist das Ergebnis eines Verbindungsversuchs am tatsächlichen Port.

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

Notieren Sie, ob die Verbindung wegen einer Zeitüberschreitung, einer Ablehnung oder einer fehlgeschlagenen Authentifizierung scheitert. Entfernen Sie vor dem Teilen von Debug-Protokollen lokale Benutzernamen, sensible Pfade und Authentifizierungsdaten.

Festplatte und Build-Cache

Prüfen Sie zunächst mit df -h / den verfügbaren Speicher. Ermitteln Sie anschließend mit du -sh ~/Library/Developer/Xcode/DerivedData den belegten Platz des Caches. Beenden Sie die zugehörigen Builds, bevor Sie projektbezogen aufräumen, damit keine gerade geschriebene Archivdatei gelöscht wird.

Behalten Sie noch auszuliefernde Artefakte, Signierungsdateien und erforderliche Protokolle. Starten Sie nach dem Aufräumen mit demselben Commit einen neuen Versuch und prüfen Sie, ob beschädigte Abhängigkeiten oder ein falscher Pfad die Ursache waren.

Hinweise zu System und Toolchain

Prüfen Sie in einer grafischen Sitzung, ob Systemdialoge oder Hinweise zum ersten Start von Xcode offen sind. Führen Sie sw_vers, xcodebuild -version und xcodebuild -showsdksaus, um zu bestätigen, dass die von CI verwendete Umgebung den Erwartungen entspricht.

Halten Sie zuerst die Jobs an und erstellen Sie eine Sicherung. Entscheiden Sie anschließend selbst, ob Sie System oder Toolchain aktualisieren. Wechseln Sie den Xcode-Pfad nicht, während ein Archive erstellt wird.

Sitzung wiederherstellen und neu starten

Beenden Sie zuerst den Remote-Client und verbinden Sie sich erneut. Wenn SSH noch funktioniert, prüfen Sie uptime und die laufenden Jobs. Melden Sie sich nur dann in der Konsole an, öffnen Sie die Instanzdetails und verwenden Sie die dort angebotene Neustartoption, wenn ein Neustart der ganzen Maschine tatsächlich nötig ist.

Ein Neustart unterbricht Builds und Remote-Verbindungen. Sichern Sie zuerst abrufbare Protokolle und Artefakte. Wenn Sie keinen Zugriff haben oder keine passende Aktion verfügbar ist, erstellen Sie ein Support-Ticket. Lösen Sie nicht wiederholt einen Neustart aus.

Problem weiterhin offen

Mit den richtigen Angaben schneller zum Ziel

Melden Sie sich in der Konsole an und erstellen Sie ein technisches Support-Ticket, damit Bestellung und Instanz zugeordnet werden können. Wenn Sie sich nicht anmelden können oder vor dem Kauf Fragen haben, schreiben Sie an support@macftp.com. Weitere Kontaktmöglichkeiten finden Sie auf der Kontaktseite.

  • Instanz zuordnen: Bestellnummer, Instanznummer, Knoten und Modell. Der Knoten befindet sich in Singapur, Tokio, Seoul oder Hongkong. Geben Sie das Modell vollständig so an, wie es in den Instanzdetails steht.
  • Situation nachvollziehbar schildern: Zeitpunkt und Zeitzone, vollständige Fehlermeldung, Schritte zur Reproduktion und ob SSH- sowie Grafikverbindung jeweils funktionieren.
  • Rückfragen vermeiden: Bereits durchgeführte Prüfungen, letzte Änderungen und bereinigte Protokollauszüge. Senden Sie keine Passwörter, privaten Schlüssel, p12-Passwörter oder vollständigen Zahlungsdaten.