Wir führen eine Testinstallation von Gitea durch und versuchen, die Gitea-LFS-zu-S3-Funktion zu verwenden. Die Konfiguration ist unkompliziert und wir haben es folgendermaßen gemacht:
[lfs]
#PATH = /opt/gitea/data/lfs
STORAGE_TYPE = minio
MINIO_ACCESS_KEY_ID = KEY
MINIO_SECRET_ACCESS_KEY = SECRET
MINIO_BUCKET = NAME
MINIO_LOCATION = us-east-1
MINIO_USE_SSL = true
SERVE_DIRECT = true
MINIO_ENDPOINT = s3.us-east-1.amazonaws.com
Das funktioniert. Ich habe ein Repo erstellt und ein anderes geklont, das mir mit der LFS-Konfiguration zur Verfügung stand. Ich konnte alle meine LFS-Dateien committen und pushen und es hat alles auf S3 hochgeladen. Das ist also großartig.
Aber jetzt habe ich ein Problem beim Klonen des Repo. Der Klon ruft zwar die Git-Dateien ab, aber beim Versuch, die LFS-Dateien auf S3 abzurufen, erhalte ich diese Meldung:
Error downloading object: FILE (hash): Smudge error: Error downloading FILE (hash): LFS: Get "https://NAME.s3.dualstack.us-east-1.amazonaws.com/lfs/PATHTOFILE": dial tcp: lookup NAME.s3.dualstack.us-east-1.amazonaws.com on IP:53: dial udp IP:53: socket: too many open files
So wie ich es verstehe, wird nur versucht, eine Datei abzurufen, aber nicht einmal das funktioniert.
Hat das schon einmal jemand gesehen?
Antwort1
Ich hatte das gleiche Problem, bin mir aber nicht sicher, was die Grundursache ist. Es scheint, dass etwas im Git-LFS-Client die direkten/signierten S3-URLs, die Gitea bereitstellt, nicht mag.
Meine Lösung bestand in der Einstellung SERVE_DIRECT = false, die grundsätzlich alle LFS-Objekte über Gitea zurückleitet, bevor sie an den Client zurückgegeben werden.