Cas d’usage
Un fichier entre deux machines
Un laptop, un poste fixe, un code. Pas de serveur, pas de compte, via le bucket que vous avez déjà.
$ s3nd put ./contract.pdf
contract.pdf · 284 kB · expires in 1 day
K7QP2M4X
# on the other machine, whenever it is on
$ s3nd get k7qp-2m4x
Wrote /home/you/contract.pdf · 284 kB
$ s3nd rm K7QP2M4X
Burned K7QP2M4XLa situation
Ce qui se passe vraiment.
Le problème
Vous avez un fichier ici et il vous le faut là-bas. L’e-mail s’étouffe dessus, une messagerie le recompresse et en garde une copie, la clé USB est dans une autre pièce, et les services hébergés veulent un compte.
Ce que s3nd y fait
Les deux machines ont des identifiants pour un bucket qui vous appartient. s3nd put envoie le fichier et affiche un code ; s3nd get de l’autre côté le télécharge ; s3nd rm le brûle. Les octets vont d’une machine au bucket et du bucket à l’autre, et rien ne transite par un service au milieu. L’autre machine n’a pas besoin d’être allumée au moment de l’envoi.
À surveiller
Les choses faciles à rater.
Lancez doctor en premier
Il effectue les opérations dont s3nd a besoin et rapporte ce qui s’est passé, y compris si une règle de cycle de vie supprimera les transferts expirés, la chose que personne ne découvre avant l’arrivée d’une facture.
Chaque machine détient les clés
Très bien pour deux ou trois machines à vous. Pour une équipe, mettez un serveur devant et distribuez des jetons plutôt que des identifiants S3.
Les dossiers voyagent en archives
tar cz ./project | s3nd put - --name project.tar.gz. Le code sort sur stdout et tout le reste sur stderr, donc ça se compose.
Voir aussi
D’autres formes de la même primitive.
Déposez un fichier. Donnez le code.
Pointez-le sur le bucket que vous payez déjà. Rien à déployer, aucune inscription, personne au milieu.