Bestellung und Knotenstatus
Prüfen Sie im Dashboard, ob die Bestellung zur Nutzung bereit ist, und gleichen Sie die aktuelle Knoten-ID ab. Maßgeblich ist der Echtzeitstatus im Dashboard.
Abnahme: Bestell- und Knoten-ID stimmen übereinPrüfen Sie zuerst im Dashboard den Knoten und die erlaubte Zugriffsquelle. Bereiten Sie anschließend Benutzername und Schlüssel vor und wählen Sie je nach Aufgabe SSH, Desktop oder eine automatisierte Sitzung. Jede NowMini-Bestellung umfasst einen exklusiven physischen M4-Rechner, keine virtuelle Maschine.
Alle sechs Informationen müssen aus derselben Bestellung und vom selben Knoten stammen. Verwenden Sie keine alte Knotenadresse, den Benutzernamen eines anderen Teammitglieds oder einen früheren Schlüssel.
Prüfen Sie im Dashboard, ob die Bestellung zur Nutzung bereit ist, und gleichen Sie die aktuelle Knoten-ID ab. Maßgeblich ist der Echtzeitstatus im Dashboard.
Abnahme: Bestell- und Knoten-ID stimmen übereinDie Auswahl umfasst Singapur, Japan (Tokio), Südkorea (Seoul) und Hongkong. Prüfen Sie, ob die Verbindungsdaten zur gewählten Region gehören, und verwenden Sie nicht die Adresse eines anderen Knotens.
Abnahme: Region und Bestelldaten stimmen übereinBenutzername, Schlüsseldatei und Gültigkeitsbereich der Zugangsdaten Zeichen für Zeichen prüfen. Private Schlüssel nur auf kontrollierten Geräten speichern, nicht per Chat oder im Repository übertragen.
Abnahme: Zugangsdaten gehören zum aktuellen NutzerPrüfen Sie, ob der aktuelle öffentliche Ausgang oder das Team-Gateway den Quellenbeschränkungen des Knotens entspricht. Nach einem Netzwerkwechsel die Ausgangsadresse erneut prüfen.
Abnahme: Aktuelle Quelle ist zugelassenZuerst Proxy, Unternehmensfirewall, öffentliches WLAN und instabile Routen als Ursachen ausschließen. Bei Bedarf über ein zweites vertrauenswürdiges Netzwerk gegenprüfen.
Abnahme: Zielport akzeptiert VerbindungenName und Version des SSH- oder Grafikclients sowie die Version des lokalen Systems dokumentieren. Im Team einheitliche Verbindungsparameter verwenden, um Clientunterschiede zu reduzieren.
Abnahme: Versionen und Parameter dokumentiertHostadresse, Benutzername und Schlüsseldatei im Befehl sind Platzhalter. Vor der Ausführung die aktuellen Knotendaten aus dem Dashboard kopieren und die Beispielzeichen nicht unverändert übernehmen.
Zuerst prüfen, dass die Datei dem aktuellen lokalen Benutzer gehört, und anschließend den Lesezugriff anderer Konten beschränken. Der Schlüsseldateiname sollte Umgebungen unterscheiden, darf aber keine echten Passwörter oder Token enthalten.
Schlüssel, Benutzername und Hostadresse explizit angeben. Bei der ersten Fehlersuche die Clientausgabe aufbewahren und Fehler nicht durch zahlreiche versteckte Parameter verschleiern.
Den beim ersten Verbindungsaufbau angezeigten Fingerabdruck mit den Angaben im Dashboard abgleichen. Wenn sich der Fingerabdruck einer bereits verwendeten Adresse geändert hat, Verbindung stoppen und den Knoteneintrag prüfen.
Nach der Anmeldung Hostname, aktuellen Benutzer, Arbeitsverzeichnis und verfügbaren Speicher prüfen. In einer noch nicht verifizierten Sitzung keinen Code, keine Zertifikate und keine Modelldateien importieren.
chmod 600 ~/.ssh/<KEY_FILE>
ssh -i ~/.ssh/<KEY_FILE> <USERNAME>@<HOST_ADDRESS>
ssh -vv -i ~/.ssh/<KEY_FILE> <USERNAME>@<HOST_ADDRESS>
hostname
whoami
pwd
df -h
Grafische Sitzungen eignen sich für Xcode, Logic Pro und Aufgaben mit Fenstern. Eine erfolgreiche Verbindung garantiert noch keine stabile Nutzung: Auflösung, Tastatur und Zwischenablage müssen separat abgenommen werden.
Die aktuellen grafischen Verbindungsdaten aus dem Dashboard abrufen und Hostadresse, Benutzername sowie Zugriffsquelle prüfen. Bei der ersten Sitzung die Standardqualität beibehalten und den stabilen Einstieg in die grafische macOS-Oberfläche bestätigen.
Schrittweise an lokalen Bildschirm und Verbindungsqualität anpassen. Eine hohe Auflösung erhöht Bandbreiten- und Codierlast. Bei anhaltendem Ruckeln zuerst die Bildgröße reduzieren und erst danach ein Knotenproblem prüfen.
Umschaltung zwischen Deutsch und Englisch sowie Command, Option, Control, Funktionstasten und gängige Tastenkürzel prüfen. Lokale Systeme können Tasten unterschiedlich abbilden; die einheitliche Teambelegung dokumentieren.
Zunächst kurzen Text ohne sensible Informationen für ein- und zweiseitiges Kopieren verwenden. Private Schlüssel, vollständige Token oder unbereinigte Produktionsdaten niemals über die Zwischenablage übertragen.
Zuerst prüfen, ob das lokale Netzwerk gewechselt hat, danach Zugriffsquelle, Clientlogs und Knotenstatus kontrollieren. Vor der Wiederverbindung nicht mehrere identische Sitzungen nacheinander erstellen, damit Desktopreaktionen nicht falsch bewertet werden.
Quellcode, temporäre Dateien und Build-Artefakte sollten nicht über denselben Synchronisierungsweg laufen. Quelle, Ziel und Aufbewahrungsdauer festlegen und danach Git, sicheren Dateitransfer oder Artefaktrückgabe wählen.
| Weg | Geeignete Inhalte | Vorgehen | Sicherheitsgrenze | Abnahmeergebnis |
|---|---|---|---|---|
| Git-Pull | Versionskontrollierter Quellcode, Skripte und Konfigurationsvorlagen | In einem separaten Arbeitsverzeichnis klonen oder pullen, Branch und Commit festlegen und Lockdateien für Abhängigkeiten dokumentieren | Keine privaten Schlüssel, Token, Signaturmaterialien oder lokalen Zugangsdaten im Repository speichern | Commit-Hash entspricht der Pipeline-Erwartung |
| Sicherer Dateitransfer | Modelldateien, Assets, temporäre Daten und nicht für das Repository geeignete Eingaben | Mit kontrolliertem Konto und eindeutigem Zielverzeichnis übertragen; anschließend Anzahl, Größe und Prüfsummen der Dateien prüfen | Nur erforderliche Verzeichnisse freigeben; Verantwortliche und Zeitpunkt für die Bereinigung temporärer Dateien festlegen | Dateien vollständig und Berechtigungen zweckgemäß |
| Build-Artefakte zurückübertragen | Archive, Logs, Testberichte, Symboldateien und auslieferbare Pakete | Nach Abschluss der Aufgabe aus dem Ausgabeverzeichnis zurückübertragen und mit Aufgabennummer, Commit-Hash und Build-Nummer benennen | Vor der Rückgabe prüfen, ob Artefakte Umgebungsvariablen, Zugangsdatenfragmente oder unbereinigte Logs enthalten | Artefakt eindeutig einer Aufgabe zuordenbar |
Geeignet für einzelne Dateien oder kleine Verzeichnisse. Host, Benutzer, Schlüssel und Pfade sind Platzhalter.
scp -i ~/.ssh/<KEY_FILE> <LOCAL_FILE> <USERNAME>@<HOST_ADDRESS>:<REMOTE_PATH>
Geeignet für wiederholbare Verzeichnisübertragungen. Vor Parametern zum Löschen den Änderungsumfang im Vorschau-Modus prüfen.
rsync -av --dry-run -e "ssh -i ~/.ssh/<KEY_FILE>" <LOCAL_PATH> <USERNAME>@<HOST_ADDRESS>:<REMOTE_PATH>
Automatisierungskonten dürfen nicht mit interaktiven Alltagskonten geteilt werden. Identität, Schlüssel, Arbeitsverzeichnis, Cache und Logs getrennt verwalten, damit sich Ursache und Berechtigung eines Fehlers nachvollziehen lassen.
Für den Runner ein dediziertes Systemkonto erstellen, das ausschließlich Automatisierungsaufgaben ausführt. Interaktive Entwicklung, grafische Sitzungen und Pipeline-Ausführung durch getrennte Identitäten abgrenzen.
Schlüssel nur die für die Aufgabe erforderlichen Anmelde- und Verzeichnisrechte geben. Für unterschiedliche Repositories, Teams oder Umgebungen verschiedene Schlüssel verwenden, damit ein Leck begrenzt bleibt.
Quellcode, Cache, temporäre Dateien und Artefakte jeweils in feste Verzeichnisse schreiben. Vor Aufgabenbeginn veränderliche Zustände bereinigen und danach notwendige Aufzeichnungen behalten.
Aufgabennummer, Commit-Hash, Start- und Endzeit, Exit-Code und Artefaktpfad dokumentieren. Felder mit Zugangsdaten in Logs müssen bereinigt werden.
Nicht gleichzeitig Netzwerk, Adresse, Schlüssel und Clientparameter ändern. Jede Schicht einzeln prüfen und Ergebnisse dokumentieren, um lokale Probleme, Zugriffsbeschränkungen, Authentifizierungsfehler und Dienststatus zu unterscheiden.
Sicherstellen, dass das Gerät normal auf das Netzwerk zugreifen kann; temporären Proxy deaktivieren, der Routen verändern könnte, und erneut versuchen. Mit einem zweiten vertrauenswürdigen Netzwerk gegenprüfen, ob das Problem am aktuellen Ausgang hängt.
Im Dashboard erlaubte Quelle mit dem aktuellen öffentlichen Ausgang abgleichen. Nach Wechsel zwischen Unternehmensnetz, mobilem Hotspot und Heimnetz kann sich die Ausgangsadresse ändern.
Sicherstellen, dass der Benutzername zum aktuellen Knoten gehört, der Pfad zum privaten Schlüssel stimmt und die lokalen Dateiberechtigungen ausreichend strikt sind. Bei Authentifizierungsfehlern nicht wahllos weitere Schlüssel versuchen.
Adresse erneut aus dem Dashboard kopieren und alte Einträge, Leerzeichen, fehlende Zeichen sowie eine Verwechslung von Knoten ausschließen. Bei Konfigurationsaliasen auch den tatsächlich aufgelösten Wert prüfen.
Im Dashboard die Echtzeitantwort von Bestellung, Knoten und Verbindungsdienst prüfen. Den Knotenstatus nicht allein anhand eines allgemeinen lokalen Clientfehlers beurteilen.
Dokumentieren, ob der Fehler beim Auflösen der Adresse, beim Aufbau der Netzwerkverbindung, bei der Protokollaushandlung, bei der Identitätsprüfung oder beim Einstieg in die Sitzung auftrat. Vor einer Supportanfrage Zugangsdaten und sensible Pfade entfernen.
Über das Dashboard ein Ticket einreichen und Bestell-ID, Knotenregion, Zeitpunkt, Reproduktionsschritte, Clientversion und bereinigte Logs beifügen. Wenn noch keine Bestellung vorliegt, den gewünschten Workflow und die bevorzugte Region über die Kontaktseite beschreiben.
Das Schließen des Fensters beendet nur einen Teil der Sitzung. Temporäre Zugangsdaten, Cache, übertragene Dateien und Berechtigungen von Teammitgliedern benötigen jeweils eine dokumentierte Behandlung.
Laufende Befehle und grafische Anwendungen ordnungsgemäß beenden und anschließend SSH- oder grafische Sitzung schließen. Prüfen, dass keine interaktiven Prozesse Arbeitsverzeichnisse oder Ausgabedateien blockieren.
Abschluss: Sitzung eindeutig beendetTemporäre Schlüssel, Token und Kontofreigaben löschen, die nur für diese Aufgabe erstellt wurden. Nach dem Widerruf prüfen, dass alte Zugangsdaten keinen Zugriff mehr auf den Knoten ermöglichen.
Abschluss: Temporärer Zugriff deaktiviertWiederverwendbaren Build-Cache, temporäre Aufgabedateien und sensible Eingaben unterscheiden. Nur Inhalte mit definiertem Zweck und Aufbewahrungszeitraum behalten; alles andere gemäß Aufgabenliste löschen.
Abschluss: Verzeichnis entspricht den AufbewahrungsregelnWenn ein Teammitglied das Projekt verlässt oder die Zuständigkeit wechselt, Zugriffsschlüssel rotieren, alte Kontoberechtigungen entfernen und prüfen, ob Runner, Skripte oder lokale Konfigurationen noch alte Zugangsdaten verwenden.
Abschluss: Mitglieder und Berechtigungen neu zugeordnetAufgabennummer, Commit-Hash, Artefaktpfad, Exit-Code, Bearbeiter und Abschlusszeit dürfen dokumentiert werden. Passwörter, private Schlüssel, vollständige Token oder sensible Geschäftsdaten gehören nicht in die Abnahmedokumentation.
Im Dashboard zuerst Bestellung, Region, Hostadresse und Zugangsdaten prüfen. Für einen neuen Knoten NowMini M4 bestellen: M4, 16 GB RAM, 256 GB SSD, exklusiver physischer Rechner, keine virtuelle Maschine.