Tâche #20675
Distribution EOLE - Scénario #20629: Traitement express MEN (23-25)
Corrections script migration25.sh
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.
Révisions associées
migration2x.sh : correction sauvegarde du ".reader"
Ref: #20675
Historique
#1 Mis à jour par Joël Cuissinat il y a presque 7 ans
- Tracker changé de Demande à Tâche
- Projet changé de Scribe à creole
- Statut changé de Nouveau à En cours
- Assigné à mis à Joël Cuissinat
- Temps estimé mis à 3.00 h
- Tâche parente mis à #20629
- Restant à faire (heures) mis à 3.0
#2 Mis à jour par Joël Cuissinat il y a presque 7 ans
- Restant à faire (heures) changé de 3.0 à 2.5
- je confirme l'erreur qui a été introduite quand on supprimé le message qui existait dans le script de migration 2.2 -> 2.3
- 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) ?
- à étudier, en effet
#3 Mis à jour par Joël Cuissinat il y a presque 7 ans
- % réalisé changé de 0 à 50
- Restant à faire (heures) changé de 2.5 à 2.0
#4 Mis à jour par Jean-Marc MELET il y a presque 7 ans
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 Mis à jour par Joël Cuissinat il y a presque 7 ans
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 Mis à jour par Jean-Marc MELET il y a presque 7 ans
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 Mis à jour par Joël Cuissinat il y a presque 7 ans
- Statut changé de En cours à Fermé
- % réalisé changé de 50 à 100
- Restant à faire (heures) changé de 2.0 à 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 Mis à jour par Jean-Marc MELET il y a presque 7 ans
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).