Hilfe für Ihren Cloud Mac

Erst selbst prüfen, dann Hilfe holen

Grenzen Sie das Problem ein – von der Verbindung über die Toolchain bis zur Verlängerung.
Wenn Sie bereits gemietet haben, reichen Sie Ihr Ticket im Kundenportal ein. Nicht erreichbare Server werden als dringende Störung priorisiert.

Tickets sind für Probleme mit bereits gemieteten Servern gedacht. Für Fragen vor dem Kauf, größere Bestellungen und Sicherheitsmeldungen nutzen Sie bitte den E-Mail-Kontakt auf der Kontaktseite.

Problem eingrenzen

Mit dem passenden Lösungsweg starten

Diese vier Problemtypen erfordern unterschiedliche Schritte. Eine noch nicht bestätigte Zahlung bedeutet nicht, dass der Server ausgefallen ist. Ein fehlgeschlagener Build lässt sich auch nicht unbedingt durch einen Neustart beheben.

Verbindung und Anmeldung

SSH-Zeitüberschreitungen, schwarzer Bildschirm auf dem Remote-Desktop oder Probleme mit der Bildschirmfreigabe. Prüfen Sie zuerst Bestelldaten und Netzwerk, bevor Sie Verbindungs- und Sitzungsebene unterscheiden.

Xcode und Simulator

Die Kommandozeile verwendet die falsche Xcode-Version, Caches belegen Speicherplatz oder das Signaturzertifikat ist nicht verfügbar. Prüfen Sie Version und Schlüsselbund, um Unterschiede in der Umgebung zu finden.

CI-Runner

Der Build läuft im Terminal, schlägt aber in der Pipeline fehl. Prüfen Sie zuerst Benutzerkonto, PATH, Schlüsselbund und Simulatorstatus – nicht die Zahl paralleler Jobs.

Zahlung und Laufzeit

Eine On-Chain-Überweisung muss noch geprüft werden, die Kartenzahlung schlägt fehl oder das Ablaufdatum ist unklar. Maßgeblich sind der Bestellstatus und das aktuelle Zahlungsergebnis im Kundenportal.

Verbindung prüfen

Erst den Port, dann die Sitzung prüfen

Host, Port, Benutzername und Anforderungen an den Schlüssel finden Sie in den Bestelldetails im Kundenportal. Passen Sie die Variablen in den folgenden Befehlen zuerst an Ihre Bestellung an. Beispielnamen sind keine echten Serveradressen.

SSH-Verbindung läuft in ein Timeout

Unterscheiden Sie zunächst zwischen einem Timeout und einem Authentifizierungsfehler. Ein Timeout tritt meist auf, bevor die TCP-Verbindung zustande kommt. Prüfen Sie daher Adresse, Port, lokalen Netzwerkausgang und Serverstatus. Bei Permission denied hat die Authentifizierung bereits begonnen – prüfen Sie Benutzername und Schlüssel, statt wiederholt den Port zu wechseln.

nc -vz "$NODE_HOST" "$SSH_PORT"

Führen Sie den Befehl in einem lokalen Terminal aus. Eine erfolgreiche Verbindung bestätigt nur, dass der Port erreichbar ist, nicht die Anmeldung. Schlägt sie fehl, wiederholen Sie die Prüfung über ein anderes verfügbares Netzwerk und notieren Sie beide Ergebnisse. Ist der Port erreichbar, die Anmeldung aber nicht, können Sie mit ssh -vv Protokolldaten zur Authentifizierung erfassen. Entfernen Sie vor dem Einreichen sensible Angaben wie Benutzernamen, Adressen und lokale Pfade.

Schwarzer Bildschirm nach VNC-Verbindung

Wenn der Client verbunden ist, aber kein Bild anzeigt, liegt ein anderes Problem vor als bei einem nicht erreichbaren Port. Trennen Sie doppelte Grafikverbindungen und prüfen Sie anschließend Bildqualität und Desktop-Sitzung im Client. Wenn SSH noch funktioniert, können Sie den aktuellen Konsolenbenutzer prüfen, um festzustellen, ob eine grafische Sitzung angemeldet ist.

stat -f '%Su' /dev/console

Führen Sie den Befehl in einer SSH-Sitzung auf dem Server aus. Die Ausgabe ist lediglich ein Anhaltspunkt und beweist nicht allein, dass der Desktopdienst funktioniert. Beenden Sie keine unbekannten Prozesse und starten Sie keinen Server neu, auf dem gerade ein Build läuft. Notieren Sie im Ticket, wann der schwarze Bildschirm auftrat, welchen Client Sie verwenden, ob SSH funktioniert und was die Sitzungsprüfung ergeben hat.

Falsche Auflösung bei der Bildschirmfreigabe

Prüfen Sie zuerst, ob sich die Auflösung auf dem Remote-Server geändert hat oder ob die Skalierung im lokalen Client den Text unscharf erscheinen lässt. Kontrollieren Sie Skalierung und adaptive Bildqualität in der Bildschirmfreigabe und rufen Sie anschließend die Anzeigeinformationen des Servers ab. Eine Änderung der Fenstergröße im Client ändert nicht automatisch den Anzeigemodus auf dem Server.

system_profiler SPDisplaysDataType

Führen Sie den Befehl auf dem Server aus und prüfen Sie die Anzeigeinformationen. Fehlt der gewünschte Modus, notieren Sie die aktuelle Auflösung, Fenstergröße des Clients und verfügbaren Anzeigemodi. Auf Screenshots sollte nur der Bereich mit den Anzeigeeinstellungen zu sehen sein – keine Projekte, Zugangsdaten oder Geschäftsdaten. Installieren Sie nicht als ersten Schritt einen Anzeigetreiber aus unbekannter Quelle.

Sind sowohl SSH als auch die Grafikverbindung nicht erreichbar und schlägt die Verbindung auch über ein anderes Netzwerk fehl, reichen Sie bitte direkt ein Ticket wegen eines nicht erreichbaren Servers ein. Eine wiederholte Neuinstallation des Clients ersetzt keine Störungsmeldung.

Entwicklungsumgebung

Terminal und Build mit derselben Toolchain ausführen

Sichern Sie zuerst die Fehlermeldung, bevor Sie die Umgebung ändern. Die folgenden Schritte gelten für Ihren dedizierten physischen Server. Stellen Sie vor Befehlen mit erhöhten Berechtigungen sicher, dass keine anderen Teamaufgaben auf die Umgebung zugreifen.

Wie wechsle ich die Xcode-Version und prüfe, welche Version die Pipeline tatsächlich verwendet?

Führen Sie zunächst xcode-select -p und xcodebuild -version aus und notieren Sie Entwicklerverzeichnis und Version. Vergewissern Sie sich, dass die gewünschte Xcode-Version installiert ist, und legen Sie anschließend ihr Verzeichnis Contents/Developer als Entwicklerverzeichnis fest. Der folgende Pfad gilt für eine Installation mit dem App-Namen Xcode.app. Verwendet der Server einen App-Namen mit Versionsnummer, passen Sie den Pfad entsprechend an.

xcode-select -p
sudo xcode-select --switch /Applications/Xcode.app/Contents/Developer
xcodebuild -version

CI-Prozesse können die systemweite Auswahl über DEVELOPER_DIR überschreiben. Unterscheiden sich die Versionen im Terminal und in der Pipeline, prüfen Sie die Umgebungsvariablen des Jobs und das Dienstkonto des Runners. Verlassen Sie sich nicht allein auf die Systemeinstellungen. Benötigt nur ein einzelner Job eine andere Version, geben Sie das Entwicklerverzeichnis direkt für diesen Job an, damit andere Builds auf demselben Server unbeeinflusst bleiben.

Wann sollte ich DerivedData löschen und wie vermeide ich, Projektdateien zu entfernen?

Prüfen Sie zuerst den Speicherbedarf und entscheiden Sie danach, ob eine Bereinigung sinnvoll ist. DerivedData kann entfernt werden, wenn nach einem Toolchain-Wechsel cachebedingte Fehler, Indexprobleme oder Platzmangel auftreten. Ein gewöhnlicher Compilerfehler ist nicht automatisch ein Cacheproblem. Beenden Sie betroffene Builds und benennen Sie den Cacheordner zunächst um. So lässt er sich bei Bedarf leichter wiederherstellen als nach dem direkten rekursiven Löschen.

du -sh "$HOME/Library/Developer/Xcode/DerivedData"
mv "$HOME/Library/Developer/Xcode/DerivedData" "$HOME/Library/Developer/Xcode/DerivedData.backup.$(date +%s)"

Benennen Sie den Ordner nur um, wenn er vorhanden ist. Xcode legt den Cache beim nächsten Build neu an. Durch das Umbenennen wird kein Speicherplatz frei. Löschen Sie den alten Cache erst, wenn der neue Build erfolgreich war und Sie den tatsächlichen Sicherungspfad geprüft haben. Bewahren Sie benötigte Archive auf und löschen Sie nicht zusammen mit dem Cache auch Archive, Projektordner oder Signaturmaterial. Verwendet CI ein benutzerdefiniertes -derivedDataPath, müssen Sie diesen Pfad prüfen und nicht den Standardordner des aktuellen Benutzers.

Warum findet der Build nach dem Import des Signaturzertifikats keine Signaturidentität?

Für eine Signaturidentität benötigen Sie ein gültiges Zertifikat und den dazugehörigen privaten Schlüssel. Eine Zertifikatsdatei allein reicht in der Regel nicht aus. Importieren Sie Signaturmaterial, zu dessen Verwendung Sie berechtigt sind, über den Schlüsselbund und prüfen Sie anschließend die verfügbaren Identitäten mit dem Benutzerkonto, unter dem der Build tatsächlich läuft. Fügen Sie weder Zertifikatsdateien noch Importpasswörter einem Ticket bei.

security find-identity -v -p codesigning
security list-keychains -d user

Eine Identität, die im interaktiven Benutzerkonto sichtbar ist, muss nicht auch für das Runner-Dienstkonto verfügbar sein. Prüfen Sie außerdem das Dienstkonto, die Schlüsselbund-Suchliste, den Entsperrstatus und die Zugriffsrechte. Wenn Sie die Zugriffssteuerung des Schlüsselbunds anpassen müssen, geben Sie nur den erforderlichen Signaturwerkzeugen Zugriff. Öffnen Sie nicht allen Apps den Zugriff auf den privaten Schlüssel, nur um einen einzelnen Fehler zu beseitigen. Für ein Ticket reichen die bereinigten Prüfergebnisse, der Fehlercode und die Art des verwendeten Benutzerkontos.

Was sollte ich prüfen, wenn der Build im Terminal, aber im CI-Runner oder Simulator fehlschlägt?

Führen Sie dieselben Umgebungsprüfungen im fehlgeschlagenen Job aus, statt sie nur im SSH-Terminal vorzunehmen. Vergleichen Sie Benutzerkonto, Entwicklerverzeichnis, Xcode-Version, PATH und verfügbare Simulatoren. Dienstprozesse laden nicht unbedingt die Konfiguration einer interaktiven Shell. Ein erfolgreicher manueller Test beweist daher nicht, dass die Dienstumgebung identisch ist.

whoami
xcode-select -p
xcodebuild -version
printf '%s\n' "$PATH"
xcrun simctl list devices available

Fehlt das gewünschte Gerät in der Simulatorliste, prüfen Sie zuerst, ob die benötigte Laufzeitumgebung installiert ist und das Ziel des Testjobs dazu passt. Wird der Runner als offline angezeigt, prüfen Sie den Dienststatus und die Jobprotokolle sowie anschließend Netzwerkverbindung und Registrierungsdaten. Liegen noch keine Vergleichswerte vor, testen Sie den Ablauf zunächst mit einem einzelnen Build. Erhöhen Sie die Parallelität schrittweise und behalten Sie gemeinsam genutzten Speicher und Festplattenbelegung im Blick.

Dedizierte Ressourcen werden nicht mit anderen Kunden geteilt. Mehrere Aufgaben auf demselben Server können sich dennoch gegenseitig beeinflussen. Die vollständigen Schritte zur Einbindung von GitHub Actions und GitLab CI finden Sie in der Verbindungsanleitung.

Zahlung und Laufzeit

Erst den Bestellstatus prüfen, dann weitermachen

Alle Preise werden in US-Dollar abgerechnet. Unterstützt werden ausschließlich USDT-TRC20 und Visa / Mastercard / Amex über Stripe. Welche Zahlungsoptionen verfügbar sind, zeigt das Kundenportal aktuell an.

USDT-TRC20 wurde gesendet. Warum ist die Zahlung bei meiner Bestellung noch nicht bestätigt?

Die Anzeige der Wallet, die Bestätigung auf der Blockchain und die Zuordnung zur Bestellung sind unterschiedliche Schritte. Die Dauer hängt von der Verarbeitung auf der Blockchain und dem Status des Zahlungsanbieters ab. Auf dieser Seite nennen wir daher keine feste Minutenzahl. Prüfen Sie zuerst Netzwerk, Empfängeradresse und Betrag wie auf der Zahlungsseite angegeben. Kontrollieren Sie anschließend, ob die Transaktion erfolgreich war, und prüfen Sie zuletzt den Bestellstatus im Kundenportal.

Leisten Sie keine zweite Zahlung, nur weil der Bestellstatus noch nicht aktualisiert wurde. Wenn eine manuelle Prüfung nötig ist, geben Sie Bestellnummer, Transaktionshash, Betrag und Überweisungszeit mit Zeitzone an. Mit dem Transaktionshash lässt sich die Zahlung zuordnen. Wiederherstellungsphrase, privater Wallet-Schlüssel und Passwort werden nicht benötigt und dürfen nicht übermittelt werden. Weichen Netzwerk oder Betrag von den Zahlungsangaben ab, bewahren Sie den Transaktionsbeleg auf und beschreiben Sie den Sachverhalt im Ticket.

Kartenzahlung fehlgeschlagen oder als ausstehend angezeigt – wie prüfe ich den Status?

Prüfen Sie zunächst die Fehlermeldung auf der Zahlungsseite und den Bestellstatus. Fragen Sie anschließend bei Ihrer kartenausgebenden Bank nach, ob die Zahlung in US-Dollar zugelassen ist und eine zusätzliche Bestätigung erforderlich ist. Eine vorgemerkte Autorisierung der Bank bedeutet nicht unbedingt, dass die Bestellung bereits bezahlt wurde. Verlassen Sie sich für den Lieferstatus nicht allein auf eine Kartenbenachrichtigung.

Scheitert die Zahlung mehrfach, fragen Sie zuerst bei Ihrer Bank nach dem Ablehnungsgrund, statt es in kurzen Abständen erneut zu versuchen. Ist die Zahlung im Kundenportal noch nicht bestätigt, die Bank weist aber bereits eine Belastung aus, geben Sie Bestellnummer, Zahlungszeit, Betrag und eine bereinigte Fehlermeldung an. Falls vorhanden, fügen Sie auch die Kennung der Zahlungstransaktion bei. Übermitteln Sie weder die vollständige Kartennummer noch Sicherheitscode oder Bestätigungscode per SMS. Unser Support gleicht Bestell- und Zahlungsdaten ab. Ob eine Rückerstattung erfolgt oder eine Autorisierung aufgehoben wurde, lässt sich erst anhand der Rückmeldung des Zahlungsanbieters und der Bank bestätigen.

Wann kommen Verlängerungserinnerungen und wie verhindere ich eine Unterbrechung meines Projekts?

Maßgeblich ist zunächst das im Kundenportal angezeigte Ablaufdatum. Den genauen Versandzeitpunkt und Status von Erinnerungen können Sie dort prüfen. Wir garantieren auf dieser Seite weder eine feste Vorlaufzeit noch sollten Sie sich für die weitere Nutzung allein auf den Eingang einer Erinnerung verlassen. Tragen Sie das Ablaufdatum am besten zusätzlich in den Teamkalender ein und bestimmen Sie eine verantwortliche Person, die das Verlängerungsergebnis prüft.

Prüfen Sie nach Auswahl eines Tages-, Wochen-, Monats- oder Quartalszeitraums, ob Gerät, Zusatzoptionen und Laufzeit auf der Verlängerungsrechnung stimmen. Vergewissern Sie sich nach der Zahlung, dass die Bestellung aktualisiert wurde, statt sich nur auf einen Screenshot der Zahlungsseite zu verlassen. Läuft die Mietzeit ohne Verlängerung ab, kann der Server nicht weiter genutzt werden. Sichern Sie Projekte, Build-Artefakte und benötigte Konfigurationen daher vor dem Ablaufdatum. Stimmen Zeit oder Betrag im Kundenportal nicht mit Ihren Erwartungen überein, notieren Sie die Rechnungsnummer und reichen Sie ein Ticket ein, bevor Sie erneut zahlen.

Die vollständigen Preise für die Laufzeiten und Speichererweiterungen finden Sie auf der Tarifseite. Bei Abrechnungsfragen zu einer bestehenden Bestellung nutzen Sie bitte ein Ticket im Kundenportal. Senden Sie keine Serverpasswörter per E-Mail.

Ticket vorbereiten

Beschreiben Sie das Problem so, dass es sich nachvollziehen lässt

Wenn Sie bereits gemietet haben, reichen Sie Ihr Ticket über das Kundenportal ein. Wir priorisieren nach Auswirkung: Nicht erreichbare Server zuerst, Fragen zu Umgebung und Abrechnung je nach Problemtyp.

Allgemeine Fragen: Erwartung und Ergebnis nennen

Fragen zur Entwicklungsumgebung, Konfiguration und Verlängerung lassen sich per Ticket klären. Als Zeitreferenz verwenden wir UTC+8 und decken die üblichen Arbeitszeiten im asiatisch-pazifischen Raum ab. Die konkreten Antwortzeiten und der Bearbeitungsstand richten sich nach den Hinweisen und Antworten im Kundenportal. Eine feste Stundenzahl wird hier nicht zugesagt.

Beschreiben Sie, was Sie tun wollten, was tatsächlich passiert ist und welche Schritte Sie bereits ausprobiert haben. Fügen Sie den kürzesten Befehl bei, mit dem sich das Problem reproduzieren lässt. Wenn mehrere Personen den Server abwechselnd nutzen, geben Sie an, ob zum fraglichen Zeitpunkt parallele Builds oder grafische Sitzungen liefen. So lassen sich Konflikte zwischen Aufgaben besser von Serverproblemen unterscheiden.

Dringende Störung: nicht erreichbare Server zuerst

Wenn sowohl SSH als auch die Grafikverbindung ausfallen und der Server für eine laufende Aufgabe nicht verfügbar ist, nennen Sie im Betreff „Server nicht erreichbar“ und geben Sie an, wann die letzte Verbindung noch funktioniert hat. Fügen Sie auch die Port-Prüfung über ein anderes Netzwerk bei. So lässt sich ein lokales Netzwerkproblem besser von einem Problem auf dem Server unterscheiden.

Die Dringlichkeitsstufe dient der Priorisierung der Prüfung und ist keine Zusage für eine feste Wiederherstellungszeit. Können Sie noch per SSH zugreifen, beschreiben Sie, welche Funktion betroffen ist. Löschen Sie keine Datenträger, installieren Sie nichts neu und trennen Sie den Server nicht wiederholt vom Strom. Das könnte die Auswirkungen vergrößern und wichtige Diagnoseinformationen vernichten.

Diese drei Angaben sollten Sie bereithalten

  1. Bestellung und Server

    Geben Sie Bestellnummer, Modell und Serverkennung an. Zur Auswahl stehen Server in Singapur, Tokio, Seoul und Hongkong. Senden Sie keine Serverpasswörter, SSH-Privatschlüssel oder Zahlungsbestätigungen.

  2. Zeit und Auswirkungen

    Notieren Sie den Beginn des Problems samt Zeitzone. Geben Sie an, ob SSH, Remote-Desktop, Build-Aufgaben oder die Zahlungsprüfung betroffen sind und wann die letzte Nutzung noch funktioniert hat.

  3. Ergebnisse und Nachweise

    Fügen Sie bereinigte Befehlsausgaben, Fehlercodes und die kürzesten Schritte zur Reproduktion bei. Entfernen Sie Projektinhalte und Zugangsdaten aus Screenshots. Ergänzen Sie Informationen nach Möglichkeit im bestehenden Ticket, damit der gesamte Verlauf erhalten bleibt.

Sie können sich nicht im Kundenportal anmelden oder möchten eine Frage vor dem Kauf, zu größeren Bestellungen oder eine Sicherheitsmeldung einreichen? Schreiben Sie an support@xcodenode.com. Senden Sie auch per E-Mail keine Passwörter, privaten Schlüssel, Signaturmaterialien oder vollständigen Kartendaten.

Noch ein Schritt: Verbindung vollständig einrichten

Die Verbindungsanleitung behandelt SSH, Remote-Desktop und CI. Wenn Sie ein Anliegen haben, das nicht Ihre Bestellung betrifft, erfahren Sie auf der Kontaktseite, welche Angaben und welcher Kontaktweg dafür vorgesehen sind.