Aws-cli: La synchronisation s3 ne préserve pas les autorisations entre les buckets

Tous les fichiers ont-ils les mêmes autorisations ? Parce que pour l'instant, vous pouvez exécuter la commande sync avec --acl pour définir les autorisations. Cependant, la commande sync cours d'exécution sans aucun autre argument facultatif ne recherche pas les autorisations et garantit que lorsque l'objet est transféré, il dispose des mêmes autorisations que l'objet d'origine. Nous devrions ajouter un argument/une fonctionnalité supplémentaire pour le gérer.

Non - si tous les fichiers avaient les mêmes autorisations, je pourrais utiliser l'indicateur --acl.

Cette fonctionnalité est vraiment indispensable dans un mécanisme de synchronisation, en particulier lorsque vous disposez de milliers de fichiers avec des autorisations différentes et que vous souhaitez une véritable synchronisation entre les compartiments, pas seulement une copie des fichiers.

Connaissez-vous un autre moyen d'obtenir des autorisations par fichier, afin que je puisse le scripter assez facilement ?

Merci pour ton aide.

Oui, si vous exécutez un aws s3api get-object-acl sur chacun des objets. Vous pourriez obtenir des ACL. Voici la doc de la commande.
http://docs.aws.amazon.com/cli/latest/reference/s3api/get-object-acl.html

OK - merci cela fonctionnera, mais cette fonctionnalité serait toujours très appréciée dans la synchronisation, sinon par défaut, l'indicateur --preserve-s3-acl conviendrait parfaitement.

Aucun problème. Considérera la fonctionnalité. Je pense que la raison pour laquelle il n'a pas été mis en œuvre est que l'opération elle-même peut être coûteuse. Pour déterminer les objets dans un compartiment s3, un appel à ListObjects est effectué, mais cela ne renvoie pas les acls pour chaque objet. À son tour, nous devrons revenir en arrière et exécuter un GetObjectAcl sur chaque objet répertorié, ce qui pourrait prendre un certain temps s'il y a des milliers d'éléments dans le seau.

Comme il m'a fallu un certain temps pour découvrir que les autorisations n'étaient pas synchronisées, peut-être que la mise à jour des documentations de s3 à s3 sync pour mentionner que seules les données et non les autorisations sont synchronisées ferait gagner du temps à quelqu'un d'autre à l'avenir.

Merci encore

des mises à jour à ce sujet ?

J'ai ajouté une pull request (#1535) pour résoudre ce problème (également d'autres transferts S3 vers S3, comme copy ) il y a quelques semaines. Y a-t-il une chance de le faire considérer pour l'inclusion?

Salut, je sais que c'est un vieux fil, mais nous avons résolu ce problème grâce à une synchronisation par type d'autorisation. Bottom line: vous pouvez filtrer votre synchronisation par nom de clé avec --exclude et --include, vous pouvez également spécifier l'ACL de chaque synchronisation ... Donc, si vous avez un modèle de clés avec vous devez définir différentes autorisations, exécutez sync plusieurs fois dont vous avez besoin avec différentes options d'ACL. C'est loin d'être idéal, mais ça marche !

Des idées de l'équipe AWS ?

Je pousse mes référentiels git vers S3 uniquement pour les sauvegardes. Et puis quand je les resynchronise, toutes sortes d'autorisations ont changé.

Tous mes fichiers bin exécutables ne sont plus exécutables et git status s'en plaint.

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1, Oui, mes buckets ont été nommés avec un point, j'ai dû changer pour être compatible avec https via cloud front. Synchronisé avec de nouveaux buckets correctement nommés. Impossible d'accéder aux fichiers. Lisez à propos des autorisations. Des autorisations au niveau de l'objet existent. Aucune commande pour modifier toutes les autorisations au niveau de l'objet dans un compartiment. Vous vous demandez comment procéder. Les autorisations via l'interface graphique aws sont identiques dans les deux compartiments, mais lorsque je consulte la liste de contrôle d'accès via le cli, je vois que le compartiment d'origine avait un bénéficiaire supplémentaire qui n'a pas été copié.
{
"Bénéficiaire": {
"Type": "Groupe",
"URI": " http://acs.amazonaws.com/groups/global/AllUsers "
},
"Autorisation": "LIRE"
}

Bonjour!

Nous fermons ce problème ici sur GitHub, dans le cadre de notre migration vers UserVoice pour les demandes de fonctionnalités impliquant l'AWS CLI.

Cela nous permettra de vous fournir les fonctionnalités les plus importantes, en facilitant la recherche et la prise en charge des fonctionnalités qui vous intéressent le plus, sans diluer la conversation avec des rapports de bogues.

En guise d'introduction rapide à UserVoice (s'il n'est pas déjà familier) : une fois qu'une idée est publiée, les gens peuvent voter sur les idées et l'équipe produit répondra directement aux suggestions les plus populaires.

Nous avons importé des demandes de fonctionnalités existantes depuis GitHub - Recherchez ce problème là-bas !

Et ne vous inquiétez pas, ce problème existera toujours sur GitHub pour la postérité. Comme il s'agit d'une importation de texte uniquement du message d'origine dans UserVoice, nous garderons toujours à l'esprit les commentaires et les discussions qui existent déjà ici sur le problème GitHub.

GitHub restera le canal pour signaler les bogues.

Encore une fois, ce problème peut maintenant être trouvé en recherchant le titre sur : https://aws.uservoice.com/forums/598381-aws-command-line-interface

-L'équipe des SDK et outils AWS

Cette entrée se trouve spécifiquement sur UserVoice à l' adresse :

@ASayre - Ce n'est peut-être pas le bon endroit pour avoir cette discussion, mais pourriez-vous expliquer pourquoi Amazon a maladroitement divisé les discussions sur l'AWS CLI entre GitHub et UserVoice ?

Les demandes de fonctionnalités semblent appropriées ici sur GitHub. Il est relativement facile de filtrer uniquement les demandes de fonctionnalités, et même de trier les plus populaires :

GitHub facilite également le partage d'extraits de code ou la référence à d'autres problèmes (comme le #1060, qui est lié à celui-ci), et une grande partie de la base d'utilisateurs de l'AWS CLI est déjà active ici sur GitHub.

Sur la base des commentaires de la communauté, nous avons décidé de renvoyer les demandes de fonctionnalités aux problèmes GitHub.

Quelqu'un a-t-il trouvé une solution décente pour y parvenir? Fonction indispensable.

La réponse ci-dessus oblige * à être lu par le public. Cela ne préserve pas les autorisations.

Quel est le progrès? Je rencontre également ce problème. Maintenant, j'utilise simplement sync --include/exclude pour résoudre ce problème.

Est-ce que quelqu'un veut me payer pour travailler là-dessus ?

4 ans et pourtant ce cauchemar continue. J'ai plus de 10 millions de fichiers et tous avec des autorisations perdues lors de la copie. Comment est-il possible qu'une chose aussi simple que le maintien des autorisations se produise ?

+1

Pour toute autre personne venant ici, j'ai pu l'utiliser pour copier un compartiment dans un autre et conserver les ACL : https://github.com/cobbzilla/s3s3mirror/tree/2.1-stable

C'est aussi nettement plus rapide.

Pour moi, j'utilise actuellement s3 pour sauvegarder mes dossiers de travail. Ceux-ci incluent les référentiels git, et mes référentiels continuent de paniquer après tous les changements d'autorisation.

Pour moi, la solution a finalement été de trouver un moyen de réinitialiser uniquement les autorisations par dépôt. Jusqu'à ce qu'AWS répare leurs déchets, c'est la solution pour moi.

git config --global --add alias.permission-reset '!git diff -p -R --no-color | grep -E "^(diff|(old|new) mode)" --color=never | git apply'

J'ai trouvé la solution ici :

https://stackoverflow.com/questions/2517339/how-to-recover-the-file-permissions-to-what-git-thinks-the-file-should-be

Salut,

J'ai rencontré le même problème - j'avais un seau avec des tonnes d'objets, alors que certains d'entre eux devraient être accessibles au public. Je devais copier l'intégralité du bucket dans un autre tout en préservant les ACL et, bien sûr, la configuration manuelle des ACL me prendrait un temps fou.

J'ai créé ce script simple en python qui copie les objets d'un compartiment à un autre et configure également les ACL pour cela.

N'hésitez pas à jeter un oeil :
https://github.com/terminator9999/aws-s3-bucket-copy/