Introduction
L'équipe de conservation des livres utilise désormais un compte destinataire dédié. Livrez Garden Atlas à son poste préparé, puis actualisez son catalogue et son traitement, ajoutez un feuillet et retirez l'ancien inventaire généré. Le destinataire doit pouvoir lire les textes livrés et exécuter le lecteur.
Ce travail commence indépendamment avec des identifiants et des dossiers préparés. Une familiarité élémentaire avec le terminal et les méthodes rsync locales du premier travail suffisent ; l'identité SSH, la vérification de l'hôte et les chemins distants sont présentés ici. Les commandes et les textes fictifs des livres restent en anglais.
Identifier le compte destinataire préparé
Dans cette étape, vous confirmerez l'identité SSH préparée et livrerez la collection au véritable compte destinataire. Utilisez Terminal. Ce travail indépendant rétablit la source et le destinataire à l'édition 1 ; il ne réutilise pas les fichiers du travail précédent.
Les deux comptes partagent cet environnement d'entraînement et son noyau. Ils représentent les deux côtés d'un déplacement, pas deux machines physiques. labex possède /home/labex/project/folder-move/old ; bindery possède /home/bindery/incoming. La racine destinataire contient sa propre note et un ancien catalogue.
SSH exécute une commande sous un autre compte via une connexion chiffrée. La clé d'identité cliente vous authentifie ; la clé d'hôte du serveur identifie le point de connexion. Leurs rôles diffèrent. La préparation a créé une clé dédiée et épinglé une clé d'hôte de confiance à partir des données de provisionnement de cet environnement. Elle n'a pas modifié l'accès de connexion de la plateforme.
cd /home/labex/project/folder-move
cat ssh/config
Host bindery-desk est un alias client. Il sélectionne l'utilisateur bindery sur 127.0.0.1, l'adresse de bouclage de ce même environnement. IdentityFile désigne votre clé privée dédiée ; n'affichez ni ne copiez son contenu. IdentitiesOnly yes sélectionne cette identité. UserKnownHostsFile désigne la clé épinglée ; StrictHostKeyChecking yes refuse un hôte inconnu ou modifié. BatchMode yes fait échouer les erreurs d'authentification sans attendre un mot de passe.
ssh-keygen -lf affiche l'empreinte d'une clé publique. Comparez la valeur SHA256: à l'empreinte de provisionnement :
ssh-keygen -lf ssh/known_hosts
cat ssh/host-fingerprint.txt
Les empreintes doivent être identiques ; les libellés et commentaires peuvent différer. Ici, le fichier de provisionnement de confiance établit l'identité attendue ; un déplacement réel exige une empreinte administrateur fiable obtenue indépendamment. Une clé uniquement recueillie sur un réseau non fiable ne suffit pas. Arrêtez-vous en cas de différence ; ne supprimez pas l'épinglage et ne désactivez pas la vérification de l'hôte.
-F ssh/config sélectionne cette configuration cliente indépendante sans remplacer vos réglages SSH habituels. Une commande entre apostrophes est transmise au destinataire ; ses chemins sont distants. Les points-virgules séparent des commandes exécutées dans l'ordre par ce shell distant. Confirmez le compte, son dossier personnel, rsync et la destination réelle avant le transfert :
ssh -F ssh/config bindery-desk 'whoami; pwd; rsync --version; ls -la /home/bindery/incoming; cat /home/bindery/incoming/receiver-note.txt'
rsync --version
Le compte est bindery, son dossier personnel est /home/bindery et les deux extrémités affichent rsync. La note conserve l'instruction concernant l'étagère ouest. Une connexion réussie au mauvais compte ne constitue pas une migration valide. Un refus de permission demande d'examiner l'identité ou les permissions du destinataire ; une alerte de changement d'hôte demande d'examiner le point de confiance. Ajouter des options non sûres ne résout aucun de ces problèmes.
Pour rsync, -e 'ssh -F ssh/config' choisit le transport SSH. La destination bindery-desk:/home/bindery/incoming/collection/ utilise le compte configuré et un chemin sur ce destinataire. Le deux-points en fait une destination distante ; un dossier local nommé remote n'utiliserait pas SSH. Conservez la barre finale de la source et le filtre déjà pratiqués :
rsync -ani -e 'ssh -F ssh/config' --exclude='*.tmp' old/collection/ bindery-desk:/home/bindery/incoming/collection/
rsync -ai -e 'ssh -F ssh/config' --exclude='*.tmp' old/collection/ bindery-desk:/home/bindery/incoming/collection/
ssh -F ssh/config bindery-desk '/home/bindery/incoming/collection/read-book'
Lisez le catalogue de Garden Atlas et le traitement à charnières de papier depuis le compte destinataire. Il s'agit d'une utilisation distante réelle du lecteur livré, avec sa configuration cachée et son droit d'exécution. Vous retrouvez ensuite l'invite locale ; une commande SSH ponctuelle ne déplace pas votre terminal local dans le dossier personnel distant.
Terminer la première livraison distante
Dans cette étape, vous livrerez l'inventaire généré séparé et lirez par SSH les données propres au destinataire ainsi que celles gérées par la source. Continuez dans Terminal, dans /home/labex/project/folder-move.
Synchronisez uniquement le répertoire géré generated/. Laissez les notes privées de personnel hors du transfert :
rsync -ani -e 'ssh -F ssh/config' old/generated/ bindery-desk:/home/bindery/incoming/generated/
rsync -ai -e 'ssh -F ssh/config' old/generated/ bindery-desk:/home/bindery/incoming/generated/
ssh -F ssh/config bindery-desk 'cat /home/bindery/incoming/generated/current.txt /home/bindery/incoming/receiver-note.txt; /home/bindery/incoming/collection/read-book'
Vous devez voir Garden Atlas | desk edition 1, la note destinataire inchangée et le lecteur utilisable. Le mode archive conserve le bit exécutable, mais les fichiers reçus appartiennent au compte destinataire ; il ne peut pas conserver n'importe quel propriétaire source. Les deux répertoires gérés sont complets sans miroir de la racine destinataire.
Si un transfert antérieur sans filtre a inclus un aperçu, examinez d'abord le fichier indésirable exact par SSH. Supprimez uniquement ce fichier temporaire avec la méthode rm du travail local. Ne supprimez ni incoming ni la note destinataire. Un filtre empêche les transferts ultérieurs mais ne nettoie pas un fichier déjà copié.
Appliquer l'édition suivante dans le périmètre géré
Dans cette étape, vous livrerez une seconde édition et retirerez uniquement l'ancien inventaire généré. Restez dans Terminal, dans /home/labex/project/folder-move. Les chemins de destination après le deux-points appartiennent au compte destinataire.
cat accepte plusieurs noms de fichiers et les affiche dans cet ordre. Lisez l'édition suivante fournie avant de remplacer la source modifiable :
cat revision/collection/texts/catalog.txt revision/collection/texts/treatment.txt revision/collection/texts/addendum.txt
Le catalogue compte maintenant 48 feuillets, le traitement utilise des charnières de lin et un supplément est nouveau. cp -a copie récursivement en conservant les attributs. revision/. désigne tout le contenu, fichiers cachés compris. La copie superpose les modifications fournies à old/ sans supprimer une entrée absente de la révision. Le poste retire explicitement old/generated/obsolete.txt : supprimez uniquement ce fichier source nommé. rm supprime définitivement un fichier ; n'élargissez pas le chemin.
cp -a revision/. old/
rm old/generated/obsolete.txt
Habituellement, rsync détermine les changements de données à partir de la taille et de la date de modification. -c ajoute une comparaison du contenu par somme de contrôle. Ces petits fichiers limitent le coût et permettent de détecter les changements de même taille avec dates conservées. Cela ne crée ni historique de versions ni sauvegarde. Simulez puis appliquez la mise à jour de la collection :
rsync -anci -e 'ssh -F ssh/config' --exclude='*.tmp' old/collection/ bindery-desk:/home/bindery/incoming/collection/
rsync -aci -e 'ssh -F ssh/config' --exclude='*.tmp' old/collection/ bindery-desk:/home/bindery/incoming/collection/
La simulation de la collection doit afficher les deux textes révisés et le nouveau supplément, sans aperçus temporaires. Des changements d'attributs seuls peuvent aussi apparaître.
--delete supprime les entrées de destination absentes de la source à l'intérieur du répertoire de synchronisation choisi. Ici, seul generated/ est entièrement géré ; la racine destinataire ne l'est pas. Simulez le retrait, repérez *deleting obsolete.txt, puis appliquez exactement le même périmètre :
rsync -anci -e 'ssh -F ssh/config' --delete old/generated/ bindery-desk:/home/bindery/incoming/generated/
rsync -aci -e 'ssh -F ssh/config' --delete old/generated/ bindery-desk:/home/bindery/incoming/generated/
ssh -F ssh/config bindery-desk 'cat /home/bindery/incoming/generated/current.txt /home/bindery/incoming/collection/texts/addendum.txt /home/bindery/incoming/receiver-note.txt'
ssh -F ssh/config bindery-desk '/home/bindery/incoming/collection/read-book'
Vous devez lire l'édition 2 du poste, le nouveau feuillet, la note d'origine et la sortie actualisée du lecteur. Un miroir de toute la racine avec --delete pourrait effacer la note. Ne l'utilisez jamais pour retirer ce seul inventaire géré.
Répétez les mêmes simulations :
rsync -anci -e 'ssh -F ssh/config' --exclude='*.tmp' old/collection/ bindery-desk:/home/bindery/incoming/collection/
rsync -anci -e 'ssh -F ssh/config' --delete old/generated/ bindery-desk:/home/bindery/incoming/generated/
Il ne devrait rester aucun changement de fichier. La répétition est sûre dans le périmètre déclaré, mais une future suppression source exigera encore une décision explicite sur le répertoire destinataire géré. rsync seul ne permet pas de récupérer l'édition originale ; utilisez une sauvegarde distincte lorsque l'historique compte.
Résumé
Vous avez livré une collection utilisable, conservé sa configuration cachée et les permissions du lecteur, ainsi que la note du poste destinataire. Une seconde synchronisation a actualisé les fichiers gérés et supprimé un ancien inventaire uniquement dans le périmètre déclaré. La synchronisation est directionnelle ; elle ne constitue ni une sauvegarde versionnée ni un outil de fusion des conflits.
