Project

General

Profile

Bac à idée #3535

Pistes de réflexion autour de la gestion des fichiers divers.

Added by Anonymous almost 8 years ago. Updated 8 months ago.

Status:
Nouveau
Priority:
Normal
Assigned To:
-
Category:
-
Target version:
-
Start date:
Due date:
% Done:

0%


Description

Je vais essayer d'exposer le plus clairement possible un problème de conflit entre fichiers statiques (non modifiables par l'utilisateur) et dynamiques (modifiables).
Nous utilisons ZEPHIR pour centraliser les configurations.
Sur ZEPHIR, nous utilisons des variantes, pour les modules.

Problème 1 : Conflit entre les versions des fichiers divers

Les "fichiers divers" des serveurs.
On peut aussi bien s'en servir pour envoyer des fichiers depuis ZEPHIR vers le serveur, que pour "remonter" ces fichiers depuis le serveur, vers ZEPHIR.

1. Admettons que je désire me servir de cette fonctionnalité uniquement pour diffuser des fichiers depuis ZEPHIR à destination du serveur
  • Si j'utilise la fonction "Envoyer la configuration au serveur" (en sélectionnant "Tout" ou "Fichiers divers/paquets") les fichiers présents sur zephir seront envoyés sur le serveur, écrasant les fichiers présents sur le serveur (ça ne me dérange pas, c'est ce que je voulais).
  • Si, en revanche, on utilise la fonction "Sauvegarder l'état actuel du serveur" (en sélectionnant "Tout" ou "fichiers divers locaux") la version des fichiers présente sur le serveur va venir écraser la version présente sur ZEPHIR.
2. Admettons maintenant que je désire me servir de cette fonctionnalité uniquement pour sauvegarder les fichiers du serveur à destination de zephir
  • Cette fois, c'est le contraire, mes données présentes sur zephir seront écrasées par la sauvegarde des fichiers du serveur (ça ne me dérange pas, c'est ce que je voulais).
  • En revanche, si j'effectue un envoi de configuration, boum, j'écrase les fichiers du serveur (qui ont peut-être évolué depuis la dernière sauvegarde vers ZEPHIR) avec ceux présents sur ZEPHIR (et donc potentiellement d'une version plus ancienne), pas glop.

Bon, là, vous allez dire, "il n'y a qu'à faire attention et n'utiliser le transfert que dans un sens".
Moi je réponds, "ben oui, mais vu que la fonctionnalité existe pour le faire dans les deux sens, pourquoi s'en priver?".

Question 1

Est-il envisageable de faire évoluer ce système en donnant la possibilité, fichier divers par fichier divers, d'indiquer que :
  1. soit le fichier présent sur le serveur sera sauvegardé vers zephir (lorsque l'on exécute la fonction "Sauvegarder l'état actuel du serveur") mais jamais écrasé par celui présent sur zephir
  2. soit le fichier présent sur zephir sera envoyé vers le serveur (lorsque l'on exécute la fonction "Envoyer la configuration au serveur") mais jamais sauvegardé vers zephir
  3. soit le fonctionnement actuel avec transfert bidirectionnel
  4. soit aucun des deux, ce qui permettrait de désactiver momentanément ce transfert

Problème 2 : fichiers divers qui écrasent de mises à jour

Sur SCRIBE 2.2.3 (en variante standard et sans aucun fichier divers personnel défini) :

  • J'installe SCRIBE -> OK
  • J'effectue l'enregistrement_zephir avec récupération de la configuration définie sur ZEPHIR (qui est une config minimaliste) -> OK
  • Je constate alors, sur ZEPHIR que des fichiers divers (présents initialement sur scribe) ont été ajoutés
  • En cherchant un peu, je constate que ces fichiers sont définis dans /usr/share/zephir/zephir_conf/fichiers_scribe

Or, un de ces emplacements est un répertoire : /usr/share/eole/backend/conf
Qui contient, notamment, le fichier icones$.conf

[icones$]
        path=/home/netlogon/icones
        browseable = No
        guest ok = Yes
        read only = no

Donc, à l'issu de l'enregistrement_zephir, j'ai sur zephir, un icones$.conf correspondant à la version initiale de SCRIBE 2.2.3.
  • Par la suite j'effectue une mise à jour de scribe, avec la dernière version de icones$.conf qui se trouve dans le paquet scribe-backend (et qui corrige le problème de notification de corbeille corrompue sous windows7). Mon SCRIBE dispose donc du dernier fichier icones$.conf (et je suis content).
[icones$]
        path=/home/netlogon/icones
        veto files = /$RECYCLE.BIN/
        delete veto files = yes
        browseable = No
        guest ok = Yes
        read only = no
  • plus tard, je décide de rajouter un fichier divers sur ce scribe (voire, sur sa variante)
  • je lance "Envoyer la configuration au serveur" et là, boum -> je me retrouve avec l'ancienne version d'icones$.conf (et les utilisateurs qui étaient contents de la résolution d'un problème le voient réapparaître d'un mauvais oeil)

Question 2

Pourquoi avoir "imposé" par fichiers_scribe, le répertoire /usr/share/eole/backend/conf en tant que "fichier divers"?
Mon avis est que des fichiers présents dans des paquets, devant rester statiques et susceptibles d'être mis à jour ne devraient jamais être sauvegardés ou renvoyés.
J'ai du pain sur la planche.

Donc, pour corriger le problème sur l'ensemble des SCRIBE, j'ai :
  1. mis en place le bon fichier icones$.conf dans la variante
  2. "Envoyer la configuration au serveur" sur mon groupe de serveurs avec le coup de chance pour moi que le fichier icones$.conf de la variante soit prioritaire sur celui défini dans "fichiers divers" (Il me semble d'ailleurs tout à fait anormal que le fichier le plus spécifique, celui défini dans fichiers divers "du serveur" ne soit pas prioritaire sur le même, défini dans fichiers divers "de la variante"). J'ai lancé cette commande "avec reconfigure" afin que smb.conf soit régénéré en prenant en compte le nouveau fichier.
  3. Ensuite, j'ai lancé un "Sauvegarder l'état actuel du serveur" avec "fichiers divers locaux" afin de faire remonter les icones$.conf sur zephir
  4. Enfin, j'ai supprimé icones$.conf de la variante
Donc, serait-il possible de faire quelquechose pour éviter ce phénomène lors d'une prochaine mise-à-jour?
  • Par la suite j'effectue une mise à jour de scribe, avec la dernière version de icones$.conf qui se trouve dans le paquet scribe-backend (et qui corrige le problème de notification de corbeille corrompue sous windows7). Mon SCRIBE dispose donc du dernier fichier icones$.conf (et je suis content).
[icones$]
        path=/home/netlogon/icones
        veto files = /$RECYCLE.BIN/
        delete veto files = yes
        browseable = No
        guest ok = Yes
        read only = no
  • plus tard, je décide de rajouter un fichier divers sur ce scribe (voire, sur sa variante)
  • je lance "Envoyer la configuration au serveur" et là, boum -> je me retrouve avec l'ancienne version d'icones$.conf (et les utilisateurs qui étaient contents de la résolution d'un problème le voient réapparaître d'un mauvais oeil)

Question 2

Pourquoi avoir "imposé" par fichiers_scribe, le répertoire /usr/share/eole/backend/conf en tant que "fichier divers"?
Mon avis est que des fichiers présents dans des paquets, et susceptibles de contenir


Related issues

Related to zephir-client - Evolution #7956: envoi / récupération de configuration : gérer le cas des fichiers livrés par des paquets Fermé

History

#1 Updated by Anonymous almost 8 years ago

Désolé pour les dernières lignes en gras

#2 Updated by Daniel Dehennin almost 8 years ago

  • Description updated (diff)

#3 Updated by Bruno Boiget almost 8 years ago

problème 1: Il y aurait effectivement des améliorations à apporter au système des fichiers divers. Dans certains cas, il manque un niveau entre les fichiers divers du serveur (modifiables dans les 2 sens) et ceux de la variante (qui ne peuvent pas remonter, mais qui ne sont pas spécifiques au serveur).

Dans la plupart des cas, il doit être possible de 'templatiser' ces fichiers et de les mettre au niveau de la variante. La partie spécifique à l'établissement étant gérée par des variables creole. Quand ce n'est pas possible, on pourrait effectivement imaginer d'interdire la remontée de ces fichiers sur Zéphir depuis le serveur (je ne sais pas si le blocage dans l'autre sens est souhaitable, c'est à voir).

problème 2: Les fichiers livrés par les paquets ne devraient effectivement pas être sauvegardés par Zéphir.
Je pense qu'à l'origine, l'idée de remonter le répertoire backend/conf était de permettre la sauvegarde des modèles de partage définis sur le serveur. Pour que ça fonctionne correctement, il faudrait séparer les modèles livrés par Eole et les modèles spécifiques au serveur (on pourrait prévoir un sous-répertoire 'local' et 'variante', comme c'est le cas pour les dictionnaires, par contre ça demande de modifier le backend pour qu'il aille chercher dans les sous-répertoires).

Pour l'ordre de priorité des fichiers, je vais faire quelques tests pour vérifier, mais normalement l'ordre de priorité (croissant) est bien le suivant:
fichiers_scribe -> fichiers_acad (si existant) -> fichiers_variante -> fichiers_zephir. Les fichiers définis au niveau serveur devraient être prioritaires.

Quelle était la version de scribe et du client zéphir ?

#4 Updated by Bruno Boiget almost 8 years ago

  • Status changed from Nouveau to En attente d'informations

#5 Updated by Anonymous almost 8 years ago

Problème 1 :
-----------
Ne pas remonter de fichiers du serveur vers la variante me semble tout à fait normal, bonjour la pagaille sinon.
Effectivement, on peut mettre des templates dans la variante pour des fichiers de configurations qui diffèrent d'un serveur à l'autre et c'est déjà ce que nous faisons pour d'autres besoins.
L'interdiction sélective de remontée des fichiers vers Zéphir me semble intéressante si elle est réversible.
J'entends par là :
  • à un instant t, mon serveur dispose de fichiers divers "cohérents" -> je lance une sauvegarde vers zephir
  • ensuite, je désire que ce soit toujours cette version qui reste sur ZEPHIR -> je désactive la remontée vers zephir de ce fichier
  • enfin, une fois le fichier local "pourri", je peux renvoyer la bonne configuration

Dans l'autre sens, interdire la descente de certains fichiers depuis zephir permet de ne pas écraser une configuration locale avec une version de fichier sur zephir trop ancienne (car la version locale n'avait pas été sauvegardée depuis longtemps)

Une autre piste serait peut-être de penser en terme de "synchronisation" (en se basant, par exemple, sur la date et la taille des fichiers, voire un hash) et synchroniser de manière automatique (dans un sens et/ou dans l'autre) afin que l'on retrouve la version la plus récente en local et sur zephir.
Je pense, ici, au cas déjà survenu où :
  • un utilisateur modifie, par l'EAD, la configuration du filtrage web de son serveur AMON
  • 3 jours plus tard, le serveur tombe en panne
  • réinstallation du serveur et remise en place des fichiers depuis zephir
  • dommage pour les modifs du filtrage si on n'avait pas fait de sauvegarde

Problème 2 :
-----------
Je pense comme vous. Une différentiation builtin/local/variante avec remontée uniquement de ce qui se trouve dans le local permettrait d'atteindre le fonctionnement souhaité, à condition de modifier le backend, mais également de mettre à jour côté serveur, et côté zephir, la liste des fichiers déjà remontés, ou inscrits pour remontée.

Zephir est en version 2.2.3 "à jour" avec zephir-client eole-117.
Mais je pense que le problème, dans le cas de scribe est que le fichier icones$.conf n'est pas présent en tant que tel dans les fichiers spécifiques au serveur, en effet, c'est le répertoire /usr/share/eole/backend/conf (en tant que répertoire) et non /usr/share/eole/backend/conf/icones$.conf qui apparaît.
fichiers_zephir -> /usr/share/eole/backend/conf
fichiers_variante -> /usr/share/eole/backend/conf/icones$.conf

Du coup, le script /usr/share/zephir/scripts/fic_modules n'a pas l'effet escompté.
/usr/share/eole/backend/conf est traité en tant que répertoire et donc "AVANT" les fichiers dans fic_modules.

/usr/share/eole/backend/conf/icones$.conf est traité en tant que fichier et ne figure que dans fichiers_variante, il ne sera donc pas écrasé par le fichier "spécifique au serveur" vu que ce dernier n'est pas défini en tant que tel.

Si je définis, en spécifique à ce serveur, le fichier /usr/share/eole/backend/conf/icones$.conf (en plus de /usr/share/eole/backend/conf), je constate que c'est bien la version spécifique qui est envoyée au scribe (comme souhaité).

Donc, j'en conclus qu'un fichier défini au niveau variante écrasera son homologue spécifique au serveur, si, au niveau spécifique, c'est le répertoire parent de ce fichier qui est défini. (effet de bord assez vicieux)

#6 Updated by Joël Cuissinat over 4 years ago

  • Project changed from Zéphir to zephir-parc

#7 Updated by Joël Cuissinat almost 2 years ago

  • Tracker changed from Anomalie to Scénario
  • Project changed from zephir-parc to Zéphir
  • Start date deleted (05/25/2012)

#8 Updated by Joël Cuissinat almost 2 years ago

  • Subject changed from Ecrasement des fichiers divers. to Pistes de réflexion autour de la gestion des fichiers divers.
  • Status changed from En attente d'informations to Nouveau
  • Release set to 26

#9 Updated by Gilles Grandgérard 8 months ago

  • Tracker changed from Scénario to Bac à idée

Also available in: Atom PDF