Cyberpunk 2077-Spielstand von Stadia zum Steam Deck übertragen

Bevor die Einstellung von Stadia bekannt gegeben wurde, spielte ich dort unter anderem Cyberpunk 2077. Wer seinen Spielstand mitnehmen möchte, der kann dies aktuell noch bewerkstelligen. Im ersten Schritt müssen dazu die entsprechenden Daten von Stadia über Google Takeout exportiert werden. Der Export für Stadia-Daten soll dabei bis mindestens zum 18. Januar noch funktionieren.

Die Spielstände können auf das Steam Deck übertragen werden

Dort finden sich im Verzeichnis Stadia/GAMING/GAME_SAVE die Spielstände. Die jeweiligen Spielstände sind gepackt und finden sich in entsprechenden ZIP-Dateien z.B. Cyberpunk 2077_1074_gamesave.zip.

Um diese Dateien auf das Steam Deck zu bringen, muss sich per SSH bzw. SFTP mit dem Steam Deck verbunden werden. Dort wird anschließend der Pfad:

~/.local/share/Steam/steamapps/compatdata/1091500/pfx/drive_c/users/steamuser/Saved Games/CD Projekt Red/Cyberpunk 2077

aufgesucht. In diesem finden sich etwaige Spielstände, in Ordnern wie ManualSave-0 oder AutoSave-1. Der Inhalt der ZIP-Dateien kann nun in einen dieser Ordner gepackt werden, oder ein neuer Ordner angelegt werden. Anschließend kann der Spielstand in Cyberpunk 2077 auf dem Steam Deck geladen werden.

SSH auf dem Steam Deck aktivieren

Da auf dem Steam Deck ein auf Arch Linux basierendes Linux läuft, kann auf diesem auch SSH aktiviert werden. Genutzt werden kann SSH unter anderem, um Dateien auf das Steam Deck zu übertragen.

Die Software des Steam Deck basiert auf Arch Linux

Im ersten Schritt muss hierzu in den Desktop-Modus gewechselt werden. Dieser wird erreicht in dem im Steam Deck-Menü der Punkt Ein/Aus ausgewählt wird. Dort findet sich dann der Punkt Zum Desktop wechseln. Wird im Desktop-Modus eine Tastatur benötigt, so kann diese über einen Druck auf die Steam-Taste in Verbindung mit dem X-Button aktiviert werden.

Über das Menü kann das Terminal bzw. die Konsole gestartet werden. Dort muss ein entsprechendes Passwort für den Nutzer deck angelegt werden:

passwd

Nachdem das Passwort für den Nutzer gesetzt wurde, kann der SSH-Dienst aktiviert werden:

sudo systemctl enable sshd

Damit wird der SSH-Dienst beim Start des Steam Deck direkt gestartet. Um ihn ohne Neustart zu aktivieren, kann der Befehl:

sudo systemctl start sshd

genutzt werden. Die IP-Adresse des Steam Deck kann mittels:

ip a

ermittelt werden. Nun kann sich per SSH, über die ermittelte IP-Adresse, mit dem Steam Deck verbunden werden:

ssh deck@192.168.2.1

Auch die Verbindung per SSH File Transfer Protocol (SFTP) zur Übertragung von Dateien ist damit möglich.

Ed25519-SSH-Schlüssel im Terminal generieren

Wer in den letzten Jahren einen SSH-Schlüssel generiert hat, wird meist RSA als kryptografischen Verfahren dafür genutzt haben. Mittlerweile geht die Empfehlung für neue Schlüssel mehrheitlich zu solchen, welche auf elliptische Kurven basieren. Ein solcher Schlüssel kann im Terminal über den Befehl:

ssh-keygen -t ed25519

generiert werden. Alternativ kann eine entsprechende E-Mail-Adresse für den Schlüssel definiert werden:

ssh-keygen -t ed25519 -C ""

Anschließend wird ein entsprechender Schlüssel erzeugt:

The key fingerprint is:
SHA256:1RCIsYVjuj9JUdpkAQEpnHmQEI2n+VsW1hr5dPk/X9w 
The key's randomart image is:
+--[ED25519 256]--+
|o*.=.o+*ooo.     |
|. O o =o=  o     |
| + o =.B .. .    |
|o   * = +.       |
| . . B oS.       |
|  . = o   .    ..|
|   + o .   .    E|
|  .   +     o  . |
|       .     o.  |
+----[SHA256]-----+

Wer sich den öffentlichen Schlüssel anschaut, wird feststellen, das dieser wesentlich kürzer ist:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDQFUwFRKdr/6xq208X6ME9kQF0pxVWSEmIkMqJXwUZ2 

Die Länge des Schlüssels verglichen mit den RSA-Schlüsseln sagt allerdings direkt nichts über die Sicherheit des Schlüssels aus. Grundsätzlich sind die Ed25519-Schlüssel kürzer als vergleichbare RSA-Schlüssel. Daneben ist das Verfahren schneller und resistenter gegen Kollisionsattacken und sollte daher in Zukunft gewählt werden.

Probleme mit rsync bei der Kompression über SSH

Ich nutze rsync in Verbindung mit dem rsync-time-backup für einfache Backups eines Servers. In letzter Zeit erhielt ich dort ein Problem mit bestimmten Dateien, welche ich synchronisieren wollte. rsync brach hier mit der Meldung:

deflate on token returned 0 (32765 bytes left)

ab. Abhilfe schaffte es hier rsync, ohne die Option –compress zu nutzen. Hier liegt wohl ein Problem bzw. ein Bug vor, der unter Umständen zu diesem Verhalten führt. Da rsync-time-backup diese Option bei einem Backup über SSH automatisch hinzufügt, habe ich die entsprechende Zeile:

RSYNC_FLAGS="$RSYNC_FLAGS --compress"

auskommentiert. Damit funktionierte der entsprechende Synchronisierungsvorgang wieder ohne Probleme. Einziger Nachteil war die erhöhte Laufzeit der Synchronisierung, da nun mehr Daten über die Leitung gesendet werden.

PHP-Version in der Shell bei all-inkl einstellen

Beim Webhoster all-inkl wird bei den größeren Paketen ein SSH-Zugang zu einer Shell mit angeboten. Mit diesem Zugang ist es unter anderem möglich PHP auf der Konsole auszuführen. Standardmäßig geschieht dies über den Befehl php. Aktuell nutzt der Befehl die Version 7.0.33 von PHP. Soll stattdessen eine höhere Version genutzt werden, so kann die symbolische Verknüpfung entsprechend verändert werden:

ln -sfv /usr/bin/php73 /usr/bin/php

Damit würde der Befehl php nun auf ein PHP in Version 7.3 zeigen. Neben der Version 7.3 sind noch weitere Versionen verfügbar:

/usr/bin/php56
/usr/bin/php70
/usr/bin/php71
/usr/bin/php72
/usr/bin/php73

Auch ohne Änderung der symbolischen Verknüfung kann die gewünschte PHP-Version verwendet werden, indem sie direkt aufgerufen wird:

/usr/bin/php72 update.php

In diesem Fall würde das Skript update.php mit der PHP-Version 7.2 ausgeführt werden.