[…] nous n’avons pas envie d’être contrôlables par quelque « Big Brother » que ce soit. Qu’il existe déjà ou que l’on anticipe son émergence, le mieux est sans doute de faire en sorte qu’il ne puisse pas utiliser, contre nous, tous ces merveilleux outils que nous offrent — ou que lui offrent — les technologies numériques. […]

Même si l’on choisit de ne pas les utiliser directement, d’autres le font pour nous. Alors, autant essayer de comprendre ce que ça implique. […]

Face à ces constats, la seule voie praticable semble être de devenir capables d’imaginer et de mettre en place des politiques de sécurité adéquates. Tout l’enjeu de ce guide est de fournir cartes, sextant et boussole à quiconque veut cheminer sur cette route.

Un guide à lire, relire, pratiquer, en solitaire ou à plusieurs, à faire découvrir et à partager… ou comment affiner l’art de la navigation dans les eaux troubles du monde numérique.

via Liandri

On a tous vécu une fois au moins la perte d'un ou de plusieurs fichiers importants que nous n'avions pas jugé bon de sauvegarder. Parfois aussi on croit disposer d'une sauvegarde et ce n'est pas le cas ! Il est donc nécessaire de mettre en place des sauvegardes périodiques et automatiques de tout ou partie de votre répertoire utilisateur.

Sous Linux, la commande de prédilection pour archiver des données est la commande rsync . Nombre de logiciels de sauvegarde sous Linux sont d'ailleurs basés sur rsync. Cette commande dispose comme beaucoup de commandes Unix et Linux de très nombreuses options qui peuvent en dérouter plus d'un. Heureusement, dans le cas d'usage qui est le notre, nous n'en avons besoin que de quelques unes. Mais que cherche t'on à faire exactement ?

On ne veux pas perdre notamment:

• les fichiers de notre répertoire $HOME, les plus importants étant dans le répertoire Documents
• certains fichiers de configuration comme .profile, .bashrc, .bash_aliases, .inputrc, .gitconfig
• les fichiers de configuration de Sublime Text, Remarkable , Emacs ou Tor Browser

En revanche, il est inutile de conserver:

• les fichiers du répertoire Téléchargements (ou Downloads)
• les fichiers situés dans Musique (ou Music)
• de nombreux répertoires commençant par un . (notamment les caches des navigateurs Internet)

Pour répondre à ce besoin, le mode archivage de la commande rsync remplit parfaitement son rôle, c'est à dire qu'il va mettre à jour notre répertoire de sauvegarde avec les fichiers ayant été modifiés depuis la dernière sauvegarde.

Dans ce mode, les options suivantes seront positionnées pour nous:

• -r, --recursive visite récursive des répertoires
• -l, --links copie les liens symboliques comme liens symboliques
• -p, --perms préserve les permissions
• -o, --owner préserve le propriétaire (root uniquement)
• -g, --group préserve le groupe
• -D, --devices préserve les périphériques (root uniquement)
• -t, --times préserve les dates

Concrètement, pour archiver les données du répertoire /home/user dans le répertoire d'archivage /media/backup, on utilisera un script similaire à celui-ci:

cat /etc/cron.daily/backup-home 
#!/bin/sh

rsync \
    --exclude '.cache' \
    --exclude '.dbus' \
    --exclude '.icons' \
    --exclude '.local' \
    --exclude '.themes' \
    --exclude 'Musique' \
    --exclude 'Téléchargements' \
    --exclude 'Vidéos' \
    --exclude 'VirtualBox VMs' \
    --verbose \
    --archive \
    --log-file=/var/log/backup-home.log \
    /home/user /media/backup

C'est à dire qu'on archive tout ce qui se trouve dans $HOME à l'exclusion d'un certain nombre de répertoires. Par exemple, je n'archive pas les machines virtuelles VirtualBox parce que cela prend beaucoup de place et personnellement ça ne m'est pas utile.

On pourrait simplifier la syntaxe utilisée pour les répertoires commençant par un point, mais le fait de préciser un à un chacun de ces répertoires me permet d'archiver mes dépôts git qui se trouvent dans Documents. De plus utiliser --exclude '.*' ne me permettra pas d'archiver par exemple .profile, .bashrc, ... ni le répertoire .mozilla qui contient le profile de Firefox avec les marques pages.

Les exclusions peuvent s'écrire plus simplement grâce à l'option --exclude-from et l'utilisation d'un fichier.

Voilà pour la sauvegarde. Pour ce qui est du coté périodique de celle-ci, j'ai utilisé anacron avec une sauvegarde quotidienne. C'est très simple, il suffit de créer ce fichier backup-home et de le placer dans le bon répertoire.

Chacun choisira la périodicité qui lui convient. On peut même faire une sauvegarde deux fois par semaine en ajoutant un code conditionnel de sortie en début du script /etc/cron.daily/backup-home.

Base64 encoding of large files.

Base64 encoding converts triples of eight-bit symbols into quadruples of six-bit symbols. Reading the input file in chunks that are a multiple of three bytes in length results in a chunk that can be encoded independently of the rest of the input file. MIME additionally enforces a line length of 76 characters plus the CRLF. 76 characters is enough for 19 quadruples of six-bit symbols thus representing 19 triples of eight-bit symbols. Reading 57 eight-bit symbols provides exactly enough data for a complete MIME-formatted line. Finally, PHP's default buffer size is 8192 bytes - enough for 143 MIME lines' worth of input.

So if you read from the input file in chunks of 8151 (=57*143) bytes you will get (up to) 8151 eight-bit symbols, which encode as exactly 10868 six-bit symbols, which then wrap to exactly 143 MIME-formatted lines. There is no need to retain left-over symbols (either six- or eight-bit) from one chunk to the next. Just read a chunk, encode it, write it out, and go on to the next chunk. Obviously the last chunk will probably be shorter, but encoding it is still independent of the rest.

while(!feof($input_file))
{
    $plain = fread($input_file, 57 * 143);
    $encoded = base64_encode($plain);
    $encoded = chunk_split($encoded, 76, "\r\n");
    fwrite($output_file, $encoded);
}

Conversely, each 76-character MIME-formatted line (not counting the trailing CRLF) contains exactly enough data for 57 bytes of output without needing to retain leftover bits that need prepending to the next line. What that means is that each line can be decoded independently of the others, and the decoded chunks can then be concatenated together or written out sequentially. However, this does make the assumption that the encoded data really is MIME-formatted; without that assurance it is necessary to accept that the base64 data won't be so conveniently arranged.

Quelques mots sur la sécurité relative au protocole TCP/IP

Tout est dans le titre. Sur un dédié uniquement, vu les manip à faire (mais je n'ai pas testé plus avant)...

À lire.

À lire. Sur le principe, c'est pas idiot.