Dissimuler un répertoire crypté avec Tomb 2.9.0 sous Debian 11
Uniquement quand on a rien à cacher... comme des fichiers avec des mots de passe, des signatures numérisées, des projets industriels...
Uniquement quand on a rien à cacher... comme des fichiers avec des mots de passe, des signatures numérisées, des projets industriels...
Dans le cas d'une vidéo et d'un fichier audio qui sont déjà calé et ont la même durée.
Et ça marche
Je souhaite faire en sorte que le répertoire local Documents, présent sur mon ordi, soit synchronisé avec le répertoire distant Documents, présent sur un hébergement web. Et bidirectionel, c'est à dire qu'une modification d'un fichier dans le répertoire local soit répercutée sur le répertoire distant, et vice versa. Si un même fichier à été modifié de façon différente de part et d'autre, on garde le dernier modifié et on sauvegarde le plus ancien.
Donc Osync c'est ici : https://github.com/deajan/osync
Pour voir une config qui fonctionne ci-après...
# fsarchiver savefs /media/tux/STOREVA/debian/2020-01-02/2020-01-02_debian.fsa /dev/nvme0n1p2 /dev/nvme0n1p4 -v -j4 -A -s 1500
Et ça marche
00. On souhaite mettre en ligne un fichier qui pourra être télécharger depuis une page statique sur un site web réalisé avec PluXml. Par exemple une affiche.
Le principe : préparer le fichier → éditer la page statique → créer un lien vers le fichier et télécharger le fichier dans le site → enregistrer la page statique → tester.
Lors de la création du futur disque crypté, il faut indiquer Filsystem type : Mac OS Extended, et ça marche
00. Avant toute chose, rester calme. Sachant que le temps que l'intrusion soit portée à notre connaissance il peut s'être écoulé... un certain temps... et que l'intervention nécessitera au moins trois temps. Un : mettre le site hors ligne. Un et demi : remettre une sauvegarde intacte en ligne, si impossible, Deux : recherche et analyse. Trois : nettoyage. Voir Quatre : correctif de la faille qui a permis l'intrusion, sinon, à quoi bon ?
Contexte :