Bac à idée #3535
Mis à jour par Daniel Dehennin il y a presque 12 ans
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.
h1. 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?".
h1. Question 1
Est-il envisageable de faire évoluer ce système en donnant la possibilité, fichier divers par fichier divers, d'indiquer que :
# 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
# 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
# soit le fonctionnement actuel avec transfert bidirectionnel
# soit aucun des deux, ce qui permettrait de désactiver momentanément ce transfert
h1. 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
<pre>
[icones$]
path=/home/netlogon/icones
browseable = No
guest ok = Yes
read only = no
</pre>
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).
<pre>
[icones$]
path=/home/netlogon/icones
veto files = /$RECYCLE.BIN/
delete veto files = yes
browseable = No
guest ok = Yes
read only = no
</pre>
* 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)
h1. 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 :
# mis en place le bon fichier icones$.conf dans la variante
# *"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.
# Ensuite, j'ai lancé un *"Sauvegarder l'état actuel du serveur"* avec *"fichiers divers locaux"* afin de faire remonter les icones$.conf sur zephir
# 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).
<pre>
[icones$]
path=/home/netlogon/icones
veto files = /$RECYCLE.BIN/
delete veto files = yes
browseable = No
guest ok = Yes
read only = no
</pre>
* 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)
h1. 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