J’ai lu (rapidement) mais j’ai pas compris.
Est ce qu’on peut avoir les spécifications exacte de ce que le système doit faire?
Pour tout dire, à un moment, je me suis dit “faire tourner ce backup à minuit répond surement à une bonne partie de la question, si cette question était dans un appel d’offre”…mais ça s’appelle “jouer au con avec les spécifications ;)”
pourquoi pas simplement une partition en RO ?
Re!
Alors tu en es ou?
Je pense que je vais utiliser une des solutions de v_atekor, modifiée par moi, pour que ce soit utilisable…
Alors ce sera moins fashion que la solution parfaite, mais bon… On va dire que les utilisateurs sont un minimum intelligent pour ne pas tomber dans les quelques panneaux que je ne pourrai pas régler…
oui, j’avais avait un tout neuf, je le fais prendre l’air, un peu de liberté de temps en temps :paf:
Parce qu’on ne peut pas écrire dedans ? Comment déposer des documents dans une partition RO ?
Alors je vais essayer de faire simple.
L’objectif est de pouvoir créer une arborescence, et déposer des documents - par exemple des comptes rendus de réunion, ou des specs fonctionnelles, bref, tout ce qui fait une bonne gestion de projet.
Ces documents doivent être référencés pour avoir un bon suivi, et donc, ne doivent pas pouvoir être modifiés par la suite.
Il faut donc pouvoir, en même temps, créer des dossiers, des sous-dossiers et des documents, et ne pas pouvoir y retoucher par la suite.
et une petite tache cron qui change les droits en r de tous les nouveaux fichiers regulierement ?
Suivant les delais de passage de la tache, y’a juste un petit moment ou le nouveau fichier est modifiable.
C’est sale, c’est moche mais ca a le merite d’etre simplet (trop ?)
Edité le 10/09/2008 à 09:21
C’est marrant de comparer les solutions “admins” et les solutions “devs” sur un même problème!
C’est exactement ce que fait mon script (d’une manière un peu plus propre, pour éviter de changer les droits sur un fichier qui est en cours de copie)
Mais ça ne marche pas, car tout connement, pour pouvoir ajouter un fichier, le répertoire doit être en W.
Et si le répertoire est en W, on peut déplacer, ou renommer le fichier qui est à l’intérieur, même s’il est en R (le R interdit juste d’en modifier le contenu).
pour la déposer sur le serveur? tu ne partages pas par samba?
Pas compris ? Si tu passes le fichier à sauvegarder en paramètre tu n’as pas forcément à le déplacer? (Ou je suis complètement à côté de la plaque?)
Non, je pense que je n’ai pas compris ton système…
Et me donner à lire un script Python, c’est pas ça qui va m’aider 
Ah ok
En fait tu as un programme qui tourne dans un groupe avec pas mal de droits (disons root, mais pas obligé)
ce programme attend de recevoir un unique ordre qui est la copie d’un fichier depuis son emplacement actuel
jusqu’à son emplacement de sauvegarde.
Il se contente de faire un copy (cp, scp … ). (ou un move … )
L’ordre lui est envoyé au travers d’une fifo, sous la forme “STORE:/chemin/vers/le/fichier”
Du côté utilisateur, tu as une commande qui s’appelle “store” qui prend un paramètre (le fichier utilisateur)
La commande se contente d’écrire dans la fifo
STORE:/chemin/vers/le/fichier
L’utilisateur ne peut pas modifier l’arborescence de stockage car il n’a pas les droits dessus (le propriétaire est root)
Il ne peut communiquer que par cette commande.
le démon crée une fifo nommée “/tmp/fifo1” (pour que l’utilisateur la retrouve, c’est presque comme un fichier)
il ouvre la fifo (comme un fichier)
et il lit ce qui arrive.
lorsqu’une commande arrive, il regarde le contenu (STORE + path)
et effectue la copy (ou le move)
et recommence au début, à attendre le prochain fichier à copier
côté commande utilisateur
elle ouvre la fifo (open, le fichier est censé être créé au paravent, mais tu peux le tester)
elle écrit dedans “STORE:path”, où path est passé en argument de la commande
et elle ferme la fifo
(tu pourrais remplacer le code user par un script bash
echo “STORE:/chemin/vers/le/fichier” > /tmp/fifo1
et c’est tout.
Edité le 10/09/2008 à 10:23
C’est grosso modo la solution que je mets en place, mais sans partie “utilisateur” et “admin”. Je n’ai qu’une partie “admin” ce qui simplifie l’extension du système à de nouveaux utilisateurs, et ce qui centralise le problème en cas de maintenance…
… mais qui te complique la vie au niveau gestion des droits. Car dans ce cas, les fichiers sont sauvés sur un répertoire ou les utilisateurs n’ont aucun accès en écriture, ni sur le répertoire ni sur le fichier : seul le démon a les droits en écriture.
et si le fichier existe déjà tu peux le vérifier et remonter une erreur simplement depuis le démon, sans crainte qu’un utilisateur passe outre.
C’est tout l’intérêt de la chose 
Edité le 10/09/2008 à 10:33
Alors ma solution prends :
un répertoire en lecture/écriture, dans lequel les gens déposent leurs document, avec l’arborescence qui va bien
un répertoire en lecture seul, qui contient les documents archivés (qui sont alors retirés du premier répertoire
un répertoire en lecture seul, qui contient les erreurs (un fichier déjà archivé, qu’on veut archiver de nouveau… pas bien !!!), avec une occurence par erreur bien sûr (des fois que le malin insiste).
Le résultat est le même qu’avec ton système je pense non ?
EDIT : finalement, le problème qu’il me reste à régler, c’est que l’option “create mask” de smb ne marche pas… Quelque soit la valeur que je mets (0770 en l’occurence), les droits restent tout le temps les mêmes (0644)
Edité le 10/09/2008 à 11:22
Oui, je crois que ça revient au même, mais comment tu ajoutes les fichiers au répertoire en lecture seule ?
un dev reinvente la roue et un admin deplace la route
tâche cron en root…
ah ok. donc oui c’est la même chose
Et la réponse de l’industriel de base pas trop inspiré par la question ça compte? :
mettre des docs comme ça dans une archive, ce n’est pas très utile.
Ce qu’il faut, c’est un moyen de les retrouver. Un soft qui gère les documents. un SGDT en français;
Ca existe en llibre mais je ne sais pas ce que ça vaut. A tester.
Sinon, un petit sgdt des familles, c’est vite fait:
une gui avec les champs classisques “auteur, date,titre du doc…” une fois ces champs remplis; un bouton pour uploader le document:
Derrière tout ça, il y a bien sûre une bonne vieille base de données. le programme stocke les champs dans la bdd ainsi que le path où il va automatiquement coper le document.
Pour l’accès au doc, il y aura des façon de faire:
soit avec une autre petite gui, “coucou sort moi tous les documents de Machin”,
soit en donnant à tout le monde un accès en Read Only à l’arboressence où sont stockées les documents (chez nous c’est du samba read only).
L’utilisateur a besion de ces deux types d’accès en pratique.
Bon après, ça va du code en C++ en ligne de commande avec une GUI en pyqt par dessus au formulaire web en passant par un code tout en tcl/tk et j’en passe.
En qlqs heures tu as un truc testable pour toi. Puis de demandes à 2 3 personnes de s’en servir…et paf.
Si ce type de choses marchent pour des très grands porjets (qlqs centaines de M), je ne vois pas pourquoi ça ne marcherait pas partout