[new:27/09/2010]J’ai un NAS, un ReadyNas NV+ 4To, une belle machine qui tourne depuis un mois et demi et dont je suis très satisfait. On peut faire plein de choses. Dont installer un serveur Subversion. Mais si les fichiers à versionner se trouvent eux-même sur le NAS, les commit plantouillent en fin de travail.
C’est une configuration non supportée donc il faut trouver un contournement.
Le ReadyNAS NV+ tourne avec un Linux, un Debian modifié par Netgear. On peut installer une version spéciale de Subversion sur le serveur, c’est vraiment un bon plan (tout le repository est protégé par le X-RAID, du Raid 5 extensible, plus les backup du NAS). Avec WebDav on dispose même d’un accès web au repository, le grand luxe quoi.
Tout fonctionne à la perfection notamment avec TortoiseSVN sur le PC plus AnkhSVN en addin de Visual Studio, un vrai bonheur.
Hélas rien n’est parfait ici bas. Le serveur Samba du NAS + subversion ça marche très bien tant que les working copies se trouvent ailleurs que sur le NAS, sur le PC donc. Mais si jamais on souhaite placer les working copies dans un des shares du NAS, ce qui peut sembler normal après tout (posséder un NAS ça sert à centraliser… s’il faut faire attention à toutes les copies se trouvant sur chaque PC ça devient moins intéressant).
Les commit marchent bien, on ne perd donc rien, mais en fin de commit on obtient une erreur fâcheuse de type Access Denied sur un déplacement / suppression de fichier. Il s’agit des fichiers de Subversion mis à jour en fin de commit. Ils sont marqués readonly par subversion et Samba refuse de supprimer, remplacer ou bouger un fichier de ce type. Il y a un petit problème, connu d’ailleurs, dans cette combinaison de logiciels et cette configuration précise (working copy placée sur le NAS).
La solution
Elle n’est pas vraiment très “propre”, mais en l’absence d’une vraie réponse : la correction du problème dans Samba ou Subversion, il faut bien se contenter d’une astuce.
Elle consiste tout simplement à modifier la configuration de Samba justement et à autoriser le delete des fichiers en readonly dans le share où on souhaite poser des working copies (ça ne sert à rien de le faire dans les autres shares et d’ouvrir des brèches…).
Pour cela :
- Lancer Putty sur le PC, se connecter au NAS en root avec le password de ce dernier
- Editer par VI le fichier /etc/frontview/samba/Shares.conf Il se présente comme un fichier INI en gros avec des sections qui sont les noms des shares.
- Dans le share (ou les shares) où le problème se pose, ajouter “delete readonly = yes” (sans les guillemets et avec les espaces).
- ZZ (pas dodo, non : sauvegarder les modifs et sortir de VI, c’est du Linux hein, tout en codes bizarres pire que MS DOS 1.0, faut en vouloir en 2010 pour se goinfrer des trucs moyenâgeux de la sorte, je vous le dit ! C’est comme un OS case sensitive dans les noms de fichier, ils veulent vraiment conquérir le monde avec une connerie pareille ?)
Bref, l’affreuse modif étant faite, Samba pourra supprimer les fichiers readonly dans le share modifié. C’est pas très malin mais ça lève le problème des commit de Subversion, et puis le mode readonly des fichiers on ne se repose pas là-dessus pour la sécurité de ses données sinon on est vraiment idiot ou inconscient, voire les deux…
Et ça marche ! Dingue.
Bon commit !
Et Stay Tuned !