14 Sep 2015, 00:00

Accéder à un partage WebDAV avec l'explorateur windows

Windows supporte l’accès aux partages WebDAV via Explorer, à condition que le service WebClient soit démarré. ce dernier est par défaut en mode manuel, et ne démarre pas lorsque l’on fait appel à un url WebDAV. Il faut donc le passer en automatique, et le démarrer à la main si on ne souhaite pas redémarrer.

Il est conseillé d’aller dans le Panneau de Configuration, dans les “Options internet”, onglet “Connexions” puis “Paramètres LAN” et de désactiver la detection automatique de la connexion. En effet, celle-ci attend un timeout de la detection d’un proxy à chaque requête WebDAV, ce qui ralentit énormément la connexion.

Ensuite, nous pouvons accéder à une URL type \\webdav.monserveur.com[@SSL][@80]\mon\dossier\partage ou encore http[s]://webdav.monserveur.com/mon/dossier/partage[:80]. Les caractères entre crochets sont à spécifier si l’on souhaite utiliser une connexion HTTPS sécurisée. De même, il est possible de spécifier un numéro de port non standard.

On peut également le conecter en tant que lecteur réseau. Si l’on coche “Mémoriser les informations d’identification”, le nom d’utilisateur sera conservé, mais pas le mot de passe, qu’il faudra malgré tout entrer à chaque ouverture de session.

Par défaut, Windows n’autorise pas le téléchargement de fichiers de plus d’une certaine taille (un fichier de 60Mo n’est pas passé). Il faut pour cela aller à la clé de registre HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters, et passer la valeur ‘FileSizeLimitInBytes’ à 4294967295 (source)

On peut également créer un batch qui permet de libérer une lettre de lecteur et de l’assigner au partage, comme ceci :

net use Z: /delete
net use Z: \\webdav.monserveur.com@SSL\mon\dossier\partage /user:monUser

03 Sep 2015, 00:00

OpenVPN en mode routé sous DD-WRT (build 13064)

Cet article décrit la mise en place d’un serveur OpenVPN configuré en mode routé (sous-réseau distinct) sous DD-WRT, build 13064.Cette build est assez ancienne, mais est la plus récente disponible pour mon WRT54GL. Les manips peuvent changer lors de versions plus récentes. Il ne couvrira que les aspects spécifiques à DD-WRT, et non la mise en place générale d’une structure PKI.

Il a pour but l’accès, à partir de l’extérieur, à tout l’intérieur d’un réseau LAN (pour l’accès aux ressources internes d’une entreprise par exemple). Il n’a PAS pour but la redirection complète du traffic réseau via VPN (usage en proxy). Par ailleurs, il part du principe qu’aucune de règle de pare-feu spécifique n’est déjà configuré.

Tout d’abord, sur un ordinateur, installer OpenVPN, Easy-RSA, et générer les clé et certificats pour le CA et le server, ainsi que les paramètres Diffie-Hellman.

Aller sur l’interface d’administration du routeur, Services -> VPN. Sous OpenVPN Daemon, cocher Enable. Pour le start-type, j’ai mis System car mon install est un peu particulière, et le routeur n’a pas de WAN (ce n’est qu’un bridge wifi). Il est toutefois souvent recommandé de cocher WAN Up.

Sous “Public Server Cert”, coller le ca.crt généré auparavant.

Sous “Certificate Revoke List”, coller le crl.pem.

Sous “Public Client Cert”, coller le server.crt.

Sous “Private Client Key”, coller le server.key.

Sous “DH PEM”, coller le dh2048.pem généré auparavant.

Sous OpenVPN config, coller ce qui suit :

	# if you want to add routes to your client
	# typically for acessing the LAN from the VPN
	push "route 192.168.1.0 255.255.255.0"

	 # definition of the VPN network
	server 10.89.0.0 255.255.255.0

	# tun for routed mode
	dev tun0
	# I always prefer UDP
	proto udp
	keepalive 10 120
	dh /tmp/openvpn/dh.pem
	ca /tmp/openvpn/ca.crt
	cert /tmp/openvpn/cert.pem
	key /tmp/openvpn/key.pem

	# you can choose other values, but it has to be in adequation with your client's config
	cipher AES-128-CBC
	comp-lzo

	# if you want VPN clients to be able to communicate together
	client-to-client

	# Only use crl-verify if you are using the revoke list
	# otherwise comment it out
	crl-verify /tmp/openvpn/ca.crl

	# management parameter allows DD-WRT's OpenVPN Status web page 
	# to access the server's management port
	# port must be 5001 for scripts embedded in firmware to work
	management localhost 5001

Cliquer sur Save, puis “Apply Settings”. On devrait alors voir, sous Status -> OpenVPN, que le serveur a bien démarré. Normalement, les clients peuvent désormais tous communiquer avec le serveur et avec les autres clients. Pour que les clients puissent communiquer avec l’intérieur du LAN cible, il faut rajouter la règle de pare-feu suivante :

	iptables -t nat -A POSTROUTING -o br0 -j MASQUERADE
	
	iptables -I INPUT 1 -p udp --dport 1194 -j ACCEPT
	iptables -I FORWARD -i br0 -o tun0 -j ACCEPT
	iptables -I FORWARD -i tun0 -o br0 -j ACCEPT

dans le cadre “Commands”, et cliquer sur Save Firewall.

Il n’y a ensuite plus qu’à configurer les clients. Voici un exemple de config fonctionnel avec les paramètres serveur ci-dessus :

client
dev tun
proto udp
remote my.domain 1194
resolv-retry infinite
nobind
persist-key
persist-tun
float

ca ca.crt
cert client.crt
key client.key
ns-cert-type server
cipher AES-128-CBC
comp-lzo
verb 2

11 May 2015, 00:00

Live-USB Hybrid Debian Jessie

Maintenant que Jessie est sortie, voici les commandes pour la création rapide d’une image Live customisée avec le bureau MATE. Ceci est basé sur la méthode pour Wheezy, avec quelques petites modifications.

sudo aptitude install live-build live-tools
mkdir jessie_live && cd jessie_live
mkdir auto && cp /usr/share/doc/live-build/examples/auto/* ./auto/

Editer le fichier auto/config pour qu’il contienne ceci :

#!/bin/sh

set -e

lb config noauto \
	--architectures 'i386' \
	--archive-areas 'main contrib non-free' \
	--bootappend-live 'boot=live config locales=fr_FR.UTF-8 keyboard-layouts=fr' \
	--binary-images 'iso-hybrid' \
	--distribution 'jessie' \
	--linux-flavours '586 686-pae amd64' \
	--source 'false' \
	"${@}"

Entrer la commande lb config, puis aller éditer le fichier config/package-lists/live.list.chroot et ajouter les paquets désirés. Je propose ceci :

live-boot
live-config
live-config-systemd
vlc mdadm rdesktop conky nmap rcconf network-manager-gnome firmware-linux firmware-atheros firmware-b43-installer firmware-bnx2x firmware-brcm80211 firmware-intelwimax firmware-ipw2x00 firmware-ivtv firmware-iwlwifi firmware-libertas firmware-myricom firmware-netxen firmware-qlogic firmware-ralink firmware-realtek gparted hfsprogs ntfs-3g hfsplus hfsutils dosfstools hplip system-config-printer xsane simple-scan lightdm mate-desktop-environment bash-completion chntpw caja-open-terminal dcfldd bootlogd less mesa-utils numlockx ethtool grub2 mesa-utils ssh gdisk testdisk python-tk iftop nethogs pm-utils dmraid chromium engrampa unrar pluma aptitude apt-file chromium-l10n smartmontools debootstrap pciutils usbutils cifs-utils e2fsprogs mtools screen pulseaudio pavucontrol pavumeter mate-media-pulse gstreamer0.10-pulseaudio mate-settings-daemon-pulse lvm2

Puis entrer la commande sudo lb build.

A noter qu’il est possible de décomposer la commande sudo lb build en la succession suivante :

sudo lb bootstrap
sudo lb chroot
sudo lb binary

Il est possible d’aller modifier/ajouter manuellement des fichiers entre l’étape chroot et l’étape binary. Par exemple, pour créer /home/user/ , /home/user/Bureau/ et y ajouter des fichiers, qui seront disponibles directement sur le bureau du live.

Si on souhaite recommencer la création du live, on peut utiliser la commande sudo lb clean qui ne conserve que le cache des paquets, du bootstrap et la config. On peut aussi utiliser les options --binary ou bien --chroot pour conserver les étapes antérieures.

07 Apr 2015, 00:00

Installer de nouvelles icônes réseau pour Dia

Cet article est un petit complément à cet article sur le blog admin-linux.org.

Les fichiers .shape proposés dans l’archive ci-présente ont été mis à jour pour intégrer un point d’ancrage principal et sont disponibles ici. Il suffit de décompresser cette archive dans ~/.dia/ pour l’utilisateur courant, et dans /usr/share/dia/ pour les ajouter au niveau système.

27 Mar 2015, 00:00

Verrouiller automatiquement une session lors de son ouverture sous Windows 7

On peut vouloir, pour diverses raisons, ouvrir une session automatiquement au démarrage de la machine, mais la verrouiller aussitôt. Pour ceci, il suffit de créer un fichier sessionLock.bat, qui contiendra cette unique ligne :

rundll32 user32.dll,LockWorkStation

Placer un raccourci vers ce fichier dans le dossier de démarrage de la session, et hop ! Lorsque la session s’ouvre, elle est immédiatement verrouillée.

09 Feb 2015, 00:00

Choisir un serveur DNS domaine par domaine sous OSX

Il est possible, sous OSX, de spécifier des serveurs DNS différents selon le domaine que l’on cherche à joindre. Ainsi, on peut avoir des domaines professionnels privés toujours accessibles, quel que soit la connexion derrrière laquelle on se trouve.

Il faut pour ceci créer le répertoire /etc/resolver/ , puis créer dedans un fichier du nom du domaine à résoudre, contenant la directive nameserver 1.2.3.4. Par exemple, pour accéder au RPVA des avocats : /etc/resolver/e-barreau.fr contiendra nameserver 192.168.1.2, avec l’adresse vers le boitier RPVA.

28 Jan 2015, 00:00

Créer une clé USB d'install de Windows 8.1 Pro|Core 64 bits, compatible Bios (MBR) et UEFI (GPT)

Pour commencer, il y a besoin d’une clé USB 8Go (ou + ), table de partition MBR, et 1 partition formatée en FAT32. Positionner le flag “boot”, mais pas besoin de positionner le flag “esp”.

Copier/coller tous les fichiers de l’ISO de Windows 8 sur la clé. Il est possible de récupérer les isos chez Microsoft . Vérifier le checksum des fichiers.

L’image telle quelle est directement bootable en UEFI. Mais elle n’installera que la version pour laquelle elle est prévue (Core ou Pro). Pour permettre le choix, ajouter dans le dosssier \Sources le fichier ei.cfg structuré tel quel :

[EditionID]

[Channel]
Retail

[VL]
0

Ensuite, il va falloir la rendre bootable en mode BIOS. Pour ceci, brancher la clé sur un Windows 64 bits, et lancer un terminal en administrateur, puis rentrer la ligne ci-dessous, en remplacant X par la lettre de la clé

X:\boot\bootsect.exe /nt60 X: /mbr

27 Oct 2014, 00:00

Cartes son multiples et ordre sous ALSA

Sur mon ordinateur portable, j’ai 2 cartes sons qui sont reconnues : le chipset de la CM, et la carte son intégrée à la carte graphique. Le système s’obstine à prendre par défaut la sortie HDMI, ce qui ne m’intéresse pas du tout. Voici ce que j’obtenais avec la commande cat /proc/asound/cards (qui liste les cartes détectées par ALSA) :

0 [Generic        ]: HDA-Intel - HD-Audio Generic
                     HD-Audio Generic at 0xf0344000 irq 45
1 [Generic_1      ]: HDA-Intel - HD-Audio Generic
                     HD-Audio Generic at 0xf0340000 irq 46

(les valeurs entre crochets sont les id des cartes).

Puis avec la commande cat /proc/asound/modules :

0 snd_hda_intel
1 snd_hda_intel

Le même pilote est donc utilisé pour les 2 cartes.

Le premier workaround que j’ai trouvé a été de demander à ALSA d’utiliser la carte avec l’inex n°1. Pour ce faire, j’ai mis dnas le fichier /etc/asound.conf :

defaults.ctl.card 1
defaults.pcm.card 1
defaults.timer.card 1

Ceci fonctionnait bien pour la lecture. Par contre, les touches de mon clavier controlant le son controllaient toujours la carte d’index 0.

J’ai donc voulu passer la carte intégrée en index 0. Il faut pour ceci éditer le fichier /etc/modprobe.d/alsa-base.conf : Echanger les numéros de slot sur les 2 première lignes :

install sound-slot-0 modprobe snd-card-0
install sound-slot-1 modprobe snd-card-1

deviennent donc

install sound-slot-1 modprobe snd-card-0
install sound-slot-0 modprobe snd-card-1

Puis ajouter à la fin :

## Carte interne avant HDMI
options snd-hda-intel id=Generic_1 index=0
options snd-hda-intel id=Generic index=1

en adaptant le nom des pilotes et les id des cartes.

Source

26 Oct 2014, 00:00

APT, Pinning et fichier preferences

RAPPEL : La gestion des priorités est à considérer comme une fonction avancée, ne remettant pas en cause les choix indiqués par le sysadmin de la machine, et pouvant facilement mener à une corruption totale du système. Il faut l’utiliser avec parcimonie, et en connaissance de cause. Ou sur une machine que l’on compte réinstaller dans la demi-heure suivante :-)

Généralités

Le système APT, via apt-get ou aptitude fait appel à un niveau de priorité, appelé Pinning, affecté à chaque paquet disponible. Lors de l’installation d’un paquet, celui installé est le paquet ayant la plus haute version parmi les paquets ayant la plus haute priorité.
Si aucune version par défaut n’est spécifiée, via la directive APT::Default-Release dans le fichier /etc/apt/apt.conf[.d/XXX] (cas par défaut sous Debian), elle affecte :

  • une prorité de 100 à tout paquet actuellement installé
  • une priorité de 500 à tout paquet disponible dans un dépôt
  • une priorité de 1 à tout paquet disponible dans un dépôt qui a la directive NotAutomatic
  • une priorité de 100 à tout paquet disponible dans un dépôt qui a la directive NotAutomatic ET la directive ButAutomaticUpdates

(Ces directives sont mentionnés dans le fichier Release que nous verrons plus loin.)

Il est possible de voir toutes les versions et priorités d’un paquet, avec la commande apt-cache policy nomdepaquet, sachant que la ligne /var/lib/dpkg/status correspond à la version actuellement installée, et donc référencée par DPKG/APT.

Le but du pinning est de modifier ces priorités par défaut, afin d’avoir, typiquement, un système complètement stable avec quelques bouts de backports, testing ou encore unstable dedans, pour les composants utiles à mettre à jour régulièrement (navigateur web, par exemple).

Affectation des priorités

Chaque entrée du fichier sources.list ramène à une URL. Lorsqu’on a une entrée du type deb http://depot.monsite.org/path/ version archive1 archive2 aptitude va chercher les infos du dépôt à l’empacement http://depot.monsite.org/path/dists/version/Release

Ce fichier Release contient plusieurs lignes, définissant le dépôt, qui aident à configurer correctement un éventuel fichier /etc/apt/preferences , ou plus proprement des fichiers /etc/apt/preferences.d/XXX.pref . Le nom de ces fichiers n’accepte que les les caractères alphanumériques, les points, les traits d’union - et les underscore _. Ils doivent avoir une extension en .pref ou pas d’extension du tout. Ces fichiers servent au pinning, c’est-à-dire la gestion avancée des versions de logiciels.

La syntaxe générale d’une entrée d’un fichier de préference est la suivante :

Package: *
Pin: keyword x=definition
Pin-Priority: integer

La ligne Package définit le ou les paquets auxquels s’applique cette entrée de pinning. Ce peut être un nom précis de paquet (iceweasel), un ensemble de paquets commençant par le même motif (iceweasel*), un ensemble de paquet contenant le même motif (/weasel/) ou tous les paquets (*).

La ligne Pin définit les sources dont les paquets seront sujets à cette entrée. Il contient un mot-clé (keyword) qui définit le mode de sélection de ces sources. Il y a 2 modes de sélection de ces sources : origin, release et version. Origin est le plus simple, il selectionne toutes les entrées sorrespondant à une url de dépot. Par exemple :

Package: *
Pin: origin "ftp.debian.org"
Pin-Priority: 990

affectera une priorité de 990 à tous les paquets de l’archive principale de Debian, quelle que soit l’archive. On ne peut pas faire plus précis avec le mot-clé origin.

Pour le mot clé release, nous pouvons spécifier plusieurs paramètres, séparés par des virgules, qui cadreront très précisément les groupe de paquets auquel s’applique le ping. Ces paramètres sont comparés avec les valeurs du fichier Release de chaque dépôt, vu plus haut. Les paramètres sont : o pour l’origine (la valeur Origin du fichier Release, à ne pas confondre avec le mot clé Origin désignant l’URL), a pour l’archive (testing, stable etc), n pour le codename (squeeze, wheezy etc), v pour la version de paquet, l pour le Label (trouvé dans le fichier Release, toujours), et c pour le composant (main, contrib, non-free etc) Par exemple :

Package: *
Pin: release o=Debian Backports,n=wheezy-backports,l=Debian Backports
Pin-Priority: 50

affectera une priorité de 50 à tous les paquets venant de l’archive wheezy-backports, on voit que les valeurs correspondent avec le fichier Release.

Le mot clé version est assez explicite. Par exemple :

Package: perl
Pin: version 5.10*
Pin-Priority: 1001

Installation de packages non-prioritaires

Le plus souvent, il suffira de fournir l’option -t à aptitude, pour lui indiquer l’archive à partir de laquelle nous souhaitons installer le paquet. Il est également possible, dans le cas de paquets de versions différentes sur le même nom d’archive (par exemple l’archive wheezy de Debian, et l’archive wheezy de deb-multimedia.org), de spécifier la version précise que nous souhaitons installer, grâce à la syntaxe paquet=version. Le numéro de version précis à entrer est celui renvoyé par apt-cache policy paquet Par exemple :

aptitude install build-essential=11.7

tentera d’installer la version 11.7 de build-essential, c’est à dire celle de Jessie. Ce paquet faisant appel à plein de paquets de jessie, qu’aptitude ne priorise pas, il ne proposera d’installer ces paquets qu’après plusieurs solutions refusées. On peut taper à la place :

aptitude install build-essential=11.7 -t jessie

ainsi nous précisons la version exacte à utiliser, tout en donnant à aptitude l’ordre d’installer à partir de jessie tout ce quie est nécessaire.

Pour plus d’informations, consultez man apt_preferences.

07 Oct 2014, 00:00

Sauvegarder via Rsync un backup Time Machine

Lorsqu’on sauvegarde avec Time Machine sur un disque réseau (fonctionnement différent du disque local), les données sont stockées au format .sparsebundle, une image disque qui s’étend à volonté, et qui contient un plusieurs anciennes versions des fichiers. Bien qu’elle apparaisse en tant que fichier sous OSX, une image qu’on peut monter dans le Finder pour en lire/écrire le contenu, c’est en réalité un dossier, qui contient quelques petits fichiers descriptifs, et surtout un gros dossiers, bands, qui contient lui-même toutes les données de l’image, découpé en fichiers de 8,4 Mo. Seule une petite partie de ces fichiers est mise à jour lors d’une sauvegarde Time Machine, et seule cette petite partie sera synchronisée via Rsync (environ 300 Mo. Il va de soi qu’avoir une connexion avec un bon upload, dans le cas d’une sauvegarde réellement distante, est un gros plus.

L’idée du script qui va suivre est de, régulièrement :

  • déclencher une sauvegarde Time Machine
  • monter le volume de sauvegarde (volume réseau, appelé “Time Capsule” ici, bien que ce puisse être n’importe quel volume proprement configuré) sur un point de montage précis
  • synchroniser le point de montage via rsync, avec un serveur ssh (par définition n’importe où dans le monde)

Les prérequis sont :

  • avoir configuré, via GUI ou autre, Time Machine, et être sûr que le setup fonctionne correctement
  • avoir configuré la redirection de ports sur le routeur devant le serveur ssh
  • avoir une configuré une authentification ssh sur le serveur via clé, sans demande de mot de passe, pour pouvoir l’automatiser
  • savoir identifier la time capsule sur le réseau, y accéder via hostname et connaître un couple user/password valide pour la lecture des données
  • avoir désactivé la planification de Time Machine. Le script s’occupe de lancer la sauvegarde, et une MAJ du contenu du sparsebundle pendant la synchronisation distante via rsync pourrait créer une incohérence dans les données.
  • avoir une système de fichiers de destination (sur le serveur ssh) qui supporte les liens durs (hard-link). Typiquement ext4. Bien qu’on stocke du HFS+, il n’est pas nécessaire que cette destination sot en HFS+, car le .sparsebundle contient un système de fichier virtuel, qui s’occupe de conserver toutes les permissions/ACL/attributs étendus nécessaires.

Voici le script proprement dit, très inspiré de cet article, avec un bon paquet de code copié/collé. Cependant, je choisis de simplement conserver les x dernières versions de la sauvegarde. En effet, Time Machine s’occupe déjà de faire un historique régulier (journalier, mensuel, annuel etc), le but de cette sauvegarde est simplement de la déporter sur un site externe, tout en pouvant retrouver une ancienne version en cas de corruption des données Time Machine, et en conservant la facilté de restauration. Ainsi, avec le paramètre daystokeep=90, nous disposons de 3 mois d’historique du contenu de la Time Capsule.

#!/bin/sh

### VARS
  # local
identifier=`hostname`
# the following folder will store lock and log files
filesPath="/path/to/folder with spaces/"  # must contain the trailing /
logfile="${filesPath}${identifier}.log"
lockfile="${filesPath}${identifier}.lck"


  # TimeCapsule (source)
  # should match the Time Machine settings (via TM GUI)
  # name is the Zeroconf name provided in the "Time Capsule" tab within the Airport Utility, finishing by .local
  # for the actual Time Capsule, username seems to be indifferent, but you need the correct password
  # for any AFP share server, username have to be correct
tc_name="Time-Capsule.local"  # it never contains spaces
tc_share="Server Backups"
tc_user="timemachine"
  # if password contains a @ sign, replace it with %40. Spaces are OK.
tc_pw="password %40 TimeCapsule"
tc_mount_point="/Volumes/TC/"  # must contain the trailing /
  # this var could be retrieved from the hostname, but is not for the moment
tc_file_name="iMac de User.sparsebundle"


  # Remote disk (destination)
ssh_user='backupuser'
ssh_server='storage.mydomain.com'
ssh_port=1111
ssh_connect="${ssh_user}@${ssh_server} -p $ssh_port "
target="/path/to/folder/" # must contain the trailing /

###  END OF VARS



# Date for this backup.
date=`date '+%Y-%m-%d_%Hh%Mm'`
# Process ID for this backup
mypid=${$}

### Log beginning of the backup
echo "\n" >> "${logfile}"
if [ ! -d "$filesPath" ]
  then mkdir "$filesPath"
  echo `date '+%Y/%m/%d %H:%M:%S '` "[${mypid}] -- $filesPath was just created" >> "${logfile}"
fi

echo `date '+%Y/%m/%d %H:%M:%S '` "[${mypid}] -- backup started" >> "${logfile}"




###  Check if process is already running to avoid multiples backups at the same time
###  which could corrupt data
if [ -f "${lockfile}" ]
then
  # Lockfile already exists, check if it belongs to a running process
  read -r lockpid < "${lockfile}" #Read the first line which contains a PID
  if [ -z "`ps -p ${lockpid} | grep ${lockpid}`" ]
  then
	# The process doesn't exist anymore. Should there be an incomple folder, it will be removed at the end of the script.
	echo `date '+%Y/%m/%d %H:%M:%S '` "[${mypid}] Lockfile for ghost process (PID: ${lockpid}) found, continuing backup." >> "${logfile}"
  else
	echo `date '+%Y/%m/%d %H:%M:%S '` "[${mypid}] Lockfile '${lockfile}' for running process (PID: ${lockpid}) found, backup stopped." >> "${logfile}"
	exit 73 # can't create (user) output file
  fi
fi
# The lockfile doesn't exist or belongs to a ghost process, make or update it containing the current PID.
echo `date '+%Y/%m/%d %H:%M:%S '` "[${mypid}] -- Création du fichier lock" >> "${logfile}"
echo ${mypid} > "${lockfile}"


### Launch the Time Machine Backup
# On OSX 10.6, the command `/System/Library/CoreServices/backupd.bundle/Contents/Resources/backupd-helper` is a "BACKUP NOW" command
#On 10.7 and later, Apple introduced the `tmutil` command which would allow to do the same
echo `date '+%Y/%m/%d %H:%M:%S '` "[${mypid}] Time Machine backup launched" >> "${logfile}"
/System/Library/CoreServices/backupd.bundle/Contents/Resources/backupd-helper

## The backupd-helper command quits before the save is really finished
## so we check the existence of the process 'backupd'
while [ `/bin/ps -arxo state,comm | /usr/bin/grep backupd | wc -l` -ne 0 ];
do
	echo `date '+%Y/%m/%d %H:%M:%S '` "[${mypid}] Time Machine backup still working. Waiting 180 seconds" >> "${logfile}"
	sleep 180
done
echo `date '+%Y/%m/%d %H:%M:%S '` "[${mypid}] Time Machine backup succeed !" >> "${logfile}"



### Check if the ssh connection can be made, a ssh keypair without keyphrase must exist.
ssh -q -q -o 'BatchMode=yes' -o 'ConnectTimeout 10' ${ssh_connect} exit &> /dev/null

if [ $? != 0 ]
then
  echo `date '+%Y/%m/%d %H:%M:%S '` "[${mypid}] SSH connection ${ssh_connect} failed." >> "${logfile}"

  # Remove lockfile
  rm -f "${lockfile}"

  exit 69 # service unavailable
fi
echo `date '+%Y/%m/%d %H:%M:%S '` "[${mypid}] SSH connection ${ssh_connect} succeed." >> "${logfile}"


### check if target exists
if ssh ${ssh_connect} "[ ! -d '${target}' ]"
then
  echo `date '+%Y/%m/%d %H:%M:%S '` "[${mypid}] Target '${target}' does not exist, backup stopped." >> "${logfile}"

  # Remove lockfile
  rm -f "${lockfile}"

  exit 66 # cannot open input
fi



### Mount the TC volume on the Filesystem
# if mountpoint doesn't exists, we create it
[ -d "$tc_mount_point" ] || mkdir "$tc_mount_point"

# mount the network disc
/sbin/mount_afp "afp://${tc_user}:${tc_pw}@${tc_name}/${tc_share}" "${tc_mount_point}"

# wait for the network disk to be actually mounted
sleep 30

### Make the actual backup of the backup

# check folder for rsync logs
if [ ! -d "${filesPath}"rsync_logs ]
then
    mkdir "${filesPath}"rsync_logs
fi

  echo `date '+%Y/%m/%d %H:%M:%S '` "[${mypid}] Rsync started." >> "${logfile}"

/usr/local/bin/rsync3 \
	-e "ssh -p $ssh_port" \
	--bwlimit=75 \
	--archive \
	--compress \
	--human-readable \
	--delete \
	"${tc_mount_point}${tc_file_name}" \
	"${ssh_user}@${ssh_server}:'${target}latest'" | tee -a "${filesPath}"rsync_logs/`date '+%Y-%m-%d_%Hh%Mm%S '

  echo `date '+%Y/%m/%d %H:%M:%S '` "[${mypid}] Rsync finished." >> "${logfile}"



### Create "history" folder if it doesn't exists
if ssh ${ssh_connect} "[ ! -d '${target}history/' ]"
then
  ssh ${ssh_connect} "mkdir '${target}history'"
fi


### archive current backup
ssh ${ssh_connect} "cp -al '${target}latest' '${target}history/${date}'"

### Remove backups older than specified days
ssh ${ssh_connect} "$target/historyClean.sh"  # this file have to be created on the backup's destination. It is detailed at the end.

### Unmount the TC Volume
/sbin/umount "${tc_mount_point}"

echo `date '+%Y/%m/%d %H:%M:%S '` "[${mypid}] Remote backup successfully finished ! " >> "${logfile}"
# Remove lockfile, this must always be done at the latest moment possible to avoid conflicting processes.
rm -f "${lockfile}"

Et voilà le script historyCleaning, qui doit être mis directement sur la machine (Unix-like) qui contient les sauvegardes du backup Time Machine (par exemple un NAS Synology).

## VARS
target="/path/to/folder/"  # path to the backup's backup. Must match the one in the main script and contain the trailing slash
tc_file_name="iMac de User.sparsebundle"  # must match the one in the main script
daystokeep=200
## END OF VARS

## We search for backups older than daystokeep ; modification time is only on the hostname.sparsebundle folder, so we search it and then we truncate the path
find "$target"history/*/* -maxdepth 0 -type d -mtime +$daystokeep | sed "s#/$tc_file_name##" > $target/dirsToRemove.txt


## We delete each folder
for j in `cat "$target"dirsToRemove.txt`
do
	# it is advised to check if everything is ok
	echo $j
	# if ok, uncomment this line
	#rm -R $j
done