s3cmd a échoué trop de fois

Et maintenant en 2014, le aws cli a la capacité de télécharger de gros fichiers au lieu de s3cmd.

http://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-set-up.html a des instructions d’installation / configuration, ou souvent:

 $ wget https://s3.amazonaws.com/aws-cli/awscli-bundle.zip $ unzip awscli-bundle.zip $ sudo ./awscli-bundle/install -i /usr/local/aws -b /usr/local/bin/aws $ aws configure 

suivi par

 $ aws s3 cp local_file.tgz s3://thereoncewasans3bucket 

vous obtiendrez des résultats satisfaisants.

Je viens de rencontrer ce problème moi-même. J’ai un fichier .tar.gz de 24 Go à mettre dans S3.

Le téléchargement de petites pièces aidera.

Il y a aussi une limite de taille de fichier d’environ 5 Go, et je divise donc le fichier en morceaux, qui peuvent être réassemblés lorsque les pièces sont téléchargées ultérieurement.

 split -b100m ../input-24GB-file.tar.gz input-24GB-file.tar.gz- 

La dernière partie de cette ligne est un préfixe. Split va y append ‘aa’, ‘ab’, ‘ac’, etc. Le -b100m signifie 100 Mo de morceaux. Un fichier de 24 Go se terminera avec environ 240 100 Mo de parties, appelées ‘input-24GB-file.tar.gz-aa’ en ‘input-24GB-file.tar.gz-jf’.

Pour les combiner plus tard, téléchargez-les tous dans un répertoire et:

 cat input-24GB-file.tar.gz-* > input-24GB-file.tar.gz 

Prendre md5sum des fichiers originaux et divisés et les stocker dans le compartiment S3, ou mieux, si ce n’est pas si important, utiliser un système comme Parchive pour pouvoir vérifier, voire corriger certains problèmes de téléchargement, pourrait également être utile.

J’ai essayé toutes les autres réponses mais aucune n’a fonctionné. Il semble que s3cmd soit assez sensible. Dans mon cas, le seau s3 était dans l’UE. Les petits fichiers sont téléchargés mais quand ils sont arrivés à ~ 60k, ils échouent toujours.

Quand j’ai changé ~ / .s3cfg cela a fonctionné.

Voici les changements que j’ai apportés:

host_base = s3-eu-west-1.amazonaws.com

host_bucket =% (bucket) s.s3-eu-west-1.amazonaws.com

J’ai eu le même problème avec Ubuntu s3cmd.

 s3cmd --guess-mime-type --acl-public put test.zip s3://www.jaumebarcelo.info/teaching/lxs/test.zip test.zip -> s3://www.jaumebarcelo.info/teaching/lxs/test.zip [1 of 1] 13037568 of 14456364 90% in 730s 17.44 kB/s failed WARNING: Upload failed: /teaching/lxs/test.zip (timed out) WARNING: Retrying on lower speed (throttle=0.00) WARNING: Waiting 3 sec... test.zip -> s3://www.jaumebarcelo.info/teaching/lxs/test.zip [1 of 1] 2916352 of 14456364 20% in 182s 15.64 kB/s failed WARNING: Upload failed: /teaching/lxs/test.zip (timed out) WARNING: Retrying on lower speed (throttle=0.01) WARNING: Waiting 6 sec... 

La solution consistait à mettre à jour s3cmd avec les instructions de s3tools.org :

Debian et Ubuntu

Notre repository DEB a été soigneusement créé de la manière la plus compatible – il devrait fonctionner pour Debian 5 (Lenny), Debian 6 (Squeeze), Ubuntu 10.04 LTS (Lucid Lynx) et pour toutes les versions Ubuntu plus anciennes. Suivez ces étapes à partir de la ligne de commande:

• Importer la clé de signature de S3tools:

  wget -O- -q http://s3tools.org/repo/deb-all/stable/s3tools.key | sudo apt-key add -

• Ajoutez le repository à sources.list:

  sudo wget -O/etc/apt/sources.list.d/s3tools.list http://s3tools.org/repo/deb-all/stable/s3tools.list

• Actualisez le cache du package et installez le plus récent s3cmd:

  sudo apt-get update && sudo apt-get install s3cmd

Cette erreur se produit lorsque Amazon retourne une erreur: il semble alors déconnecter le socket pour vous empêcher de télécharger des gigaoctets de requête pour récupérer “no, failed” en réponse. C’est la raison pour laquelle certaines personnes l’obtiennent en raison d’un décalage d’horloge, certaines personnes l’obtiennent en raison d’erreurs de stratégie et d’autres rencontrent des limitations de taille nécessitant l’utilisation de l’API de téléchargement en plusieurs parties. Ce n’est pas que tout le monde a tort ou regarde même des problèmes différents: ce sont tous des symptômes différents du même comportement sous-jacent dans s3cmd.

Comme la plupart des conditions d’erreur sont déterministes, le comportement de s3cmd consistant à rejeter le message d’erreur et à réessayer plus lentement est un peu fou :(. Pour obtenir le message d’erreur, vous pouvez aller dans / usr / share / s3cmd / S3 / S3.py (rappelez-vous de supprimer le fichier .pyc correspondant pour que les modifications soient utilisées) et ajoutez une print e dans la fonction send_file except Exception, e: block.

Dans mon cas, j’essayais de définir le type de contenu du fichier téléchargé sur “application / x-debian-package”. Apparemment, le fichier S3.object_put 1 de s3cmd n’honore pas un Content-Type transmis via –add-header et pourtant 2) ne remplace pas le Content-Type ajouté via –add-header car il stocke les en-têtes dans un dictionnaire. touches sensibles. Le résultat est qu’il effectue un calcul de signature en utilisant sa valeur de “content-type”, puis se termine (du moins avec de nombreuses requêtes; cela peut être basé sur une sorte de commande de hachage quelque part) en envoyant “Content-Type” à Amazon, menant à l’erreur de signature.

Dans mon cas particulier aujourd’hui, il semblerait que -M obligerait s3cmd à deviner le bon Content-Type, mais il semble faire cela uniquement en fonction du nom de fichier … J’aurais espéré qu’il utiliserait la firebase database mimemagic basée sur le contenu du fichier. Honnêtement, cependant: s3cmd ne parvient même pas à renvoyer un état de sortie de shell en échec quand il ne parvient pas à télécharger le fichier, donc, combiné à tous ces autres problèmes, il est probablement préférable d’écrire votre propre outil unique Ce dont vous avez besoin … il est presque certain qu’à la fin, vous gagnerez du temps lorsque vous serez mordu par un cas en particulier de cet outil :(.

s3cmd 1.0.0 ne supporte pas encore les multi-parties. J’ai essayé 1.1.0-beta et ça marche très bien. Vous pouvez lire sur les nouvelles fonctionnalités ici: http://s3tools.org/s3cmd-110b2-released

Dans mon cas, la raison de l’échec était que le serveur était en avance sur l’heure S3. Depuis que j’ai utilisé GMT + 4 sur mon serveur (situé dans l’est des États-Unis) et que j’utilisais l’installation de stockage d’Amazon USA Est.

Après avoir ajusté mon serveur à l’heure de l’est des États-Unis, le problème a disparu.

J’ai rencontré le même problème, il s’est avéré être une mauvaise valeur de bucket_location dans ~/.s3cfg .

Ce billet de blog m’a conduit à la réponse.

Si le compartiment sur lequel vous transférez n’existe pas (ou si vous l’avez raté), il échouera avec cette erreur. Merci message d’erreur générique. – Voir plus sur: http://jeremyshapiro.com/blog/2011/02/errno-32-broken-pipe-in-s3cmd/#sthash.ZbGwj5Ex.dpuf

Après avoir inspecté mon ~/.s3cfg est vu qu’il avait:

 bucket_location = Sydney 

Plutôt que:

 bucket_location = ap-southeast-2 

La correction de cette valeur pour utiliser le ou les noms appropriés a résolu le problème.

Pour moi, les suivants ont fonctionné:

Dans .s3cfg, j’ai changé le host_bucket

 host_bucket = %(bucket)s.s3-external-3.amazonaws.com 

La version s3cmd 1.1.0-beta3 ou supérieure utilisera automatiquement les téléchargements en plusieurs parties pour permettre l’envoi de fichiers volumineux ( source ). Vous pouvez également contrôler la taille du bloc. par exemple

 s3cmd --multipart-chunk-size-mb=1000 put hugefile.tar.gz s3://mybucket/dir/ 

Cela fera le téléchargement en morceaux de 1 Go.

J’ai rencontré la même erreur de tube cassé que la stratégie de groupe de sécurité a été définie de manière incorrecte. Je blâme la documentation de S3.

J’ai écrit sur la façon de définir la stratégie correctement dans mon blog, à savoir:

 { "Statement": [ { "Effect": "Allow", "Action": [ "s3:ListBucket", "s3:GetBucketLocation", "s3:ListBucketMultipartUploads" ], "Resource": "arn:aws:s3:::example_bucket", "Condition": {} }, { "Effect": "Allow", "Action": [ "s3:AbortMultipartUpload", "s3:DeleteObject", "s3:DeleteObjectVersion", "s3:GetObject", "s3:GetObjectAcl", "s3:GetObjectVersion", "s3:GetObjectVersionAcl", "s3:PutObject", "s3:PutObjectAcl", "s3:PutObjectAclVersion" ], "Resource": "arn:aws:s3:::example_bucket/*", "Condition": {} } ] } 

Dans mon cas, j’ai résolu ce problème en ajoutant simplement les permissions appropriées.

 Bucket > Properties > Permissions "Authenticated Users" - List - Upload/Delete - Edit Permissions 

J’ai rencontré une erreur similaire qui s’est finalement avérée être causée par une dérive de temps sur la machine. Définir correctement l’heure a résolu le problème pour moi.

Recherchez le fichier .s3cfg , généralement dans votre dossier personnel.

Si vous l’avez, vous avez le méchant. La modification des deux parameters suivants devrait vous aider.

 socket_timeout = 1000 multipart_chunk_size_mb = 15 

Je me suis attaqué à cela simplement en n’utilisant pas s3cmd. Au lieu de cela, j’ai eu un grand succès avec le projet python, S3-Multipart sur GitHub . Il télécharge et télécharge, en utilisant autant de threads que vous le souhaitez.