Project

General

Profile

Tâche #20675

Distribution EOLE - Scénario #20629: Traitement express MEN (23-25)

Corrections script migration25.sh

Added by Jean-Marc MELET over 3 years ago. Updated over 3 years ago.

Status:
Fermé
Priority:
Normal
Assigned To:
Start date:
05/30/2017
Due date:
% Done:

100%

Estimated time:
3.00 h
Spent time:
Remaining (hours):
0.0

Description

Bonjour,

Sauf erreur de notre part nous avons relevé 3 problèmes lors de l'utilisation du script de migration en version 2.5 concernant les modules Horus et Scribe:

1) A la ligne 532, la condition du test de présence du fichier .reader devrait être inversée:

[ -f /root/.reader ] && cp -f /root/.reader "$1/$READER"

au lieu de
[ ! -f /root/.reader ] && cp -f /root/.reader "$1/$READER"

Sinon le fichier n'est jamais sauvegardé et cela génère notamment un echec lors de l'authentification SSO sur le nouveau module.

2) Dans les fonctions savescribedata/restorescribedata et savehorusdata/restorehorusdata, il manque la sauvegarde et la restauration des fichiers aquota.user et aquota.group présents à la racine de la partition montée sur /home. En effet, nous avons remarqué que sans cela la restauration des quotas par la fonction restorequota renvoie des erreurs "quotatool: Error while detecting kernel quota version: No such process" et les quotas définis sur la partition ne sont pas restaurés.
En ajoutant ces lignes aux fonctions savescribedata et savehorusdata:

quotaoff /home    
/bin/cp -pf /home/aquota.* $1/
echo

Et ces lignes aux fonctions restorescribedata et restorehorusdata:
quotaoff /home
/bin/cp -pf $1/aquota.* /home/
quotaon /home

Les quotas sont correctement restaurés.

3) L'execution de la fonction savemail peut générer des messages d'erreur indésirables lors du traitement de certain fichiers avec des chemins longs et des caractères spéciaux. Ex:

2017/05/30 17:00:43 [32444] rsync: mkstemp "/media/migration/scribe-0139998X/mail/admin/.Poubelle/cur/.1372521324.M152870P28548V000000000000FC03I00000000000230A3_1.scribe,S=1197:2,S.U07tfM" failed: No such file or directory (2)

Pour ce problème, je n'ai pas encore pu étudier de solution de contournement.

Associated revisions

Revision b6834dbf (diff)
Added by Joël Cuissinat over 3 years ago

migration2x.sh : correction sauvegarde du ".reader"

Ref: #20675

History

#1 Updated by Joël Cuissinat over 3 years ago

  • Tracker changed from Demande to Tâche
  • Project changed from Scribe to creole
  • Status changed from Nouveau to En cours
  • Assigned To set to Joël Cuissinat
  • Estimated time set to 3.00 h
  • Parent task set to #20629
  • Remaining (hours) set to 3.0

#2 Updated by Joël Cuissinat over 3 years ago

  • Remaining (hours) changed from 3.0 to 2.5
  1. je confirme l'erreur qui a été introduite quand on supprimé le message qui existait dans le script de migration 2.2 -> 2.3
  2. concernant les quotas, les fichiers spéciaux aquota sont volontairement exclus de la sauvegarde mais leur migration est effectivement assurée par l'appel aux commandes repquota puis setquota (lignes 367 et suivantes). L'erreur "quotatool: Error while detecting kernel quota version: No such process" vient du fait que le service quota est mal mis en place sur le module, tu restaure bien après instance (cf. #16160) ?
  3. à étudier, en effet

#3 Updated by Joël Cuissinat over 3 years ago

  • % Done changed from 0 to 50
  • Remaining (hours) changed from 2.5 to 2.0

#4 Updated by Jean-Marc MELET over 3 years ago

OK pour les points 1 et 3.
Pour le point 2, oui on restaure bien apres instance et on tombe sur cette erreur si les fichiers aquota ne sont pas présent sur /home. Même si j'ai trouvé ça bizarre, j'en ai conclu qu'il fallait aussi récupérer ces fichiers en plus de la sauvegarde faite par repquota et du coup je pensais que c'était un oubli. J'ai lu https://dev-eole.ac-dijon.fr/issues/16160 mais même en lançant "quotaon -avug" avant la restauration j'ai ces erreurs, mais il faudrait que je refasse le test sur une nouvelle migration complète de serveur depuis le début.
Sinon quel serait la contre-indication à restaurer en plus les fichiers aquota sur /home?

#5 Updated by Joël Cuissinat over 3 years ago

Si on essaie de restaurer les fichiers "aquota" à chaud et qu'ils sont déjà présents (ce qui est censé être le cas après instance), on obtient une erreur :

root@scribe:~# > /home/aquota.user
-bash: /home/aquota.user: Permission non accordée
root@scribe:~# rm -f /home/aquota.user
rm: impossible de supprimer «/home/aquota.user»: Opération non permise

#6 Updated by Jean-Marc MELET over 3 years ago

Mais en désactivant les quotas avant comme indiqué dans mon premier dialogue (quotaoff /home) pour les réactiver ensuite ça ne pose pas de problème non?

#7 Updated by Joël Cuissinat over 3 years ago

  • Status changed from En cours to Fermé
  • % Done changed from 50 to 100
  • Remaining (hours) changed from 2.0 to 0.0

Jean-Marc MELET a écrit :

Mais en désactivant les quotas avant comme indiqué dans mon premier dialogue (quotaoff /home) pour les réactiver ensuite ça ne pose pas de problème non?

Comme ça ça devrait marcher... Ceci dit l'application avec setquota le devrait également et elle a l'avantage de ne pas restaurer les éventuelles limites appliquées à des utilisateurs supprimés (ceux apparaissant avec leur uidNumber dans repquota).

Je propose d'en rester là pour cette demande mais tu peux toujours essayer de relancer le débat sur les listes ;)

#8 Updated by Jean-Marc MELET over 3 years ago

Je veux bien mais au final sur la question des quotas, pour nous le script n'est pas fonctionnel en l'état puisqu'on a ces erreurs à l'application de setquota si on ne restaure pas avant les fichiers aquota de l'ancien module à la racine de /home (maintenant peut-être que ce problème est propre à notre installation mais je ne vois pas ce que nous aurions fait ou oublié de faire qui l'expliquerait, d'ou mon signalement).

Also available in: Atom PDF