blog.name.nil?

Après plusieurs mois d’utilisation de timemachine sur un serveur linux fournissant du samba le tout via wifi (en 802.11n pour un minimum de performances), je n’ai constaté aucun problème de fiabilité des données. Il suffit de lancer une commande simple dans le terminal pour que timemachine voit de nouveau les montages réseau, de plus, cette commande résiste aux reboots :

defaults write com.apple.systempreferences TMShowUnsupportedNetworkVolumes 1

A noter que cette commande n’est actuellement plus nécessaire suite à la sortie de timecapsule et des mises à jour qui ont suivi. Petit bémol cependant : elle ne semble fonctionner qu’avec des serveurs samba, exit donc les serveurs NFS plus performants et moins gourmands en mémoire que leurs homologues samba. Ceci dis, cela permet d’obtenir un timemachine utilisant un nas dans un environnement relativement standard.

Voulant maintenant utiliser timemachine sur une de mes machine de bureau et donc vierge de tout disque timemachine, il me faut créer le volume. J’ai donc monté le volume souhaité via le Finder, choisi celui-ci dans la configuration de timemachine et lancé la première opération de backup. Mais il semble qu’il y ait une limite qu’apple a décidé d’imposer aux disques réseaux pour vendre sa timecapsule : la création de l’image disque échoue. Un petit tour dans les logs et sur le filer pour se rendre compte qu’il y a bien une étape de création d’une image disque, qu’elle est correctement écrite mais au moment d’en faire le montage cela échoue ‘magiquement’ :

Mar 27 22:46:44 cola /System/Library/CoreServices/backupd[36785]: Backup requested by user
Mar 27 22:46:44 cola /System/Library/CoreServices/backupd[36785]: Starting standard backup
Mar 27 22:46:44 cola /System/Library/CoreServices/backupd[36785]: Creating disk image /Volumes/timemachine-cola/cola_001a92566c28.sparsebundle
Mar 27 22:46:52 cola kernel[0]: hfs: Initializing the journal (joffset 0x322000 sz 0x800000)...
Mar 27 22:46:55 cola com.apple.KernelEventAgent[63]: KernelEventAgent: sysctl_queryfs: No such file or directory
Mar 27 22:46:55 cola /System/Library/CoreServices/backupd[36785]: Backup requested due to disk attach
Mar 27 22:46:55 cola /System/Library/CoreServices/backupd[36785]: Error 45 creating backup disk image
Mar 27 22:46:55 cola /System/Library/CoreServices/backupd[36785]: Failed to create disk image
Mar 27 22:46:55 cola /System/Library/CoreServices/backupd[36785]: Backup failed with error: 20

L’ensemble des fichier de l’image est effacé après échec de la création. Mais une soixantaine de mega-octets ont tout de même été copiés. Apprenant qu’il faut copier les fichiers avant leur effacement pour les remettre juste après afin d’obtenir un timemachine fonctionnel, on ne peut penser qu’il ne s’agit que d’un hack de dernière minute de la part d’Apple pour bloquer les disques réseaux n’affichant pas de pomme. Un petit watch exécuté sur le serveur de fichiers pour copier constamment les données de l’image disque lors de sa création et le tour est joué :

watch -n 0.1 cp -Rvpd . /tmp/timemachine

On remet les fichier en place et … timemachine peut maintenant utiliser le nas pour sauvegarder.

Testons donc cette solution, on installe le paquet (avahi-daemon dans mon cas sur debian) et on configure un service. C’est un fichier xml indiquant au daemon quel service il doit annoncer. Pour un exemple simple d’annonce d’un serveur samba, ca donne ca :

?xml version="1.0" standalone='no'?>
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">

<service-group>
    <name replace-wildcards="yes">%h filer</name>
    <service>
        <type>_smb._tcp</type>
        <port>139</port>
        <host-name>cortex.storage.geekspirit.net</host-name>
    </service>
</service-group>

On attend … encore … et rien sur la workstation. Je pense à ma topologie réseau un peu spéciale : mes serveurs ne sont pas sur le même réseau que mes workstations. Exit donc les possibilité de broadcast qui pourraient faire correctement marcher un service tel que celui-ci. Mais pas grave, fouillons les options de configuration pour voir si un moyen de transmettre les données d’un avahi à l’autre. Et ca paie : l’attribut enable-reflector permet cette petite fonctionnalité. On installe donc un petit avahi sur le firewall qui est situé entre les 2 réseaux et qui fait le pont, on mets l’option à yes et … ca marche !

Mais ca ne me convient qu’à moitié : je préfère du nfs. On tente donc le coup avec cette fois ci ce service :

<!DOCTYPE service-group SYSTEM "avahi-service.dtd">

<service-group>
<name replace-wildcards="yes">pics</name>
<service>
    <type>_nfs._tcp</type>
    <port>2049</port>
    <txt-record>path=/exports/pics</txt-record>
    <host-name>cortex.storage.geekspirit.net</host-name>
</service>
</service-group>

Et déception, rien ne s’affiche. Après quelques recherches, j’apprends que sous léopard ca ne marche pas avec nfs. Mais un script permet de rechercher les services nfs puis s’occupe de monter tout seul chaque point de montage. Ca serait presque parfait si on pouvait même le lancer au login. Le seul hic, c’est qu’en mettant le script dans les startup items, ca ne fait qu’ouvrir xcode avec le script en question. Une petite astuce pour lancer des scripts : retirer l’extension. Ca n’est pas très beau, mais léopard croit voir un script unix et lance un terminal pour l’exécuter.

Et voila, à l’invite on se retrouve avec un beau montage tout fait tout propre, remis à jour dynamiquement grace à bonjour et toutes les personnes squattant ici avec un mac pourront maintenant voir directement les serveurs sur lesquels se servir ou m’offrir.