Anomalie #4085
Scribe 2.3 problème de montage bacula
Description
Suite à deux installations de scribe 2.3 (peux être horus est-il aussi concerné, je n'ai pas testé), le test de montage bacula est en erreur d'écriture dans l'ead lorsque l'on configure la sauvegarde.
Sur les deux serveurs, j'ai constaté en effectuant un /usr/share/eole/bacula/baculamount.py --mount , puis un "ll /mnt" :
drwxr-xr-x 3 root root 4096 2012-09-18 15:32 sauvegardes
Puis /usr/share/eole/bacula/baculamount.py --umount donne :
drwxr-xr-x 2 bacula root 4096 2012-09-14 09:48 sauvegardes
J'ai donc les deux fois faire la manipulation suivante :
/usr/share/eole/bacula/baculamount.py --mount
chown bacula /mnt/sauvegardes/
/usr/share/eole/bacula/baculamount.py --umount
Et là la sauvegarde est ok dans l'ead.
Je ne sais pas ou se situe exactement le problème, mais cela fait que bacula n'est pas immédiatement utilisable après installation.
En effet, si on lance une sauvegarde immédiate, on a dans les log bacula:
ClientRunBeforeJob: touch: impossible de faire un touch «/mnt/sauvegardes/eole_test.txt»: Permission non accordée
Related issues
Associated revisions
try to fix - see #4085
git-svn-id: https://forge.glpi-project.org/svn/ocsinventoryng@141 521019e7-676f-4c92-9f5a-82357c860469
« test_bacula_support » ne renvoi pas les valeurs de « test_mount_point »
- pyeole/bacula.py (test_bacula_support): Ajout d’un « return ».
Ref: #4085 @15m
La détermination du statut du montage ne donne pas d'informations sur les causes d'échec.
L'action de l'EAD était basée sur l'interception d'une exception
pour déterminer le statut du test du montage.
Les sorties des fonctions du test de montage et du montage ont
été modifiées pour délivrer plus d'informations sur l'erreur.
L'action de l'EAD récupère le résultat des fonctions de pyeole
et détermine le statut à afficher selon ce résultat.
Ref #4085
La sortie de la fonction de test du montage n'est pas exploitable.
L'action de l'EAD était basé sur l'interception d'une exception
pour déterminer le statut du test du montage.
Les sorties des fonctions du test de montage et du montage ont
été modifiées pour délivrer plus d'informations sur l'erreur dans
ce commit.
L'action de l'EAD récupère le résultat des fonctions de pyeole
et détermine le statut à afficher selon ce résultat.
Ref #4085
History
#1 Updated by Daniel Dehennin about 11 years ago
L’uid de l’utilisateur bacula n’est pas réservé.
Du coup lors d’une installation 2.3, l’uid de l’utilisateur bacula peut ne pas être le même que sur le serveur 2.2.
Je ne suis pas chaud personnellement pour faire un chown automatiquement au montage, cela risque de cacher de possibles problèmes.
Par exemple, si quelqu’un utilise le disque sur sa machine, il est probable qu’il fasse un chown pour avoir l’accès.
Ne pas avoir le bon propriétaire sur le système de fichier nécessite, à mon avis, une remonté d’alerte.
Il faut en revanche, gérer le cas où c’est une migration avec changement d’uid.
#2 Updated by Emmanuel GARETTE about 11 years ago
Sur 2.2 la sauvegarde se fait en root (avec patch sur le démon bacula). Il n'y a pas de problème de droit et les fichiers n'appartiennent pas à bacula.
Il faudrait peut être prévoir quelque chose dans le script de migration ?
#3 Updated by Claude Perrin about 10 years ago
- Target version set to Mises à jour 2.3.11
Le problème reste le même pour tout nouveau disque dur installé sur le serveur en 2.3 current
Soit on fait un chown
soit il serait bien d'avoir un message plus explicite.
Temps perdu à comprendre l'erreur EAD jusqu'à lire ce bug 60mn
Malgré l'aide de Lyon
http://nefertiti.crdp.ac-lyon.fr/wk/cdch/sauvegarde_restauration
Merci d'avance
#4 Updated by Joël Cuissinat about 10 years ago
- Project changed from Scribe to eole-bacula
- Status changed from Nouveau to A étudier
- Assigned To set to Daniel Dehennin
- Start date deleted (
09/18/2012)
#5 Updated by Cédric Frayssinet almost 10 years ago
En effet, sans chown pas de sauvegarde :/
#6 Updated by Daniel Dehennin almost 10 years ago
- Assigned To changed from Daniel Dehennin to developpeurs_eole
L’appel à /usr/share/eole/bacula/baculamount.py -t renvoyait None.
Maintenant j’ai:
root@horus:~# /usr/share/eole/bacula/baculamount.py -t
{'is_right_node': True, 'has_rights': False, 'is_busy': True}
Il faut maintenant que l’EAD gère correctement ces valeurs
#7 Updated by Fabrice Barconnière almost 10 years ago
- Due date set to 11/08/2013
#8 Updated by Fabrice Barconnière almost 10 years ago
- Due date changed from 11/08/2013 to 11/15/2013
Un paquet sera refait avec ces corrections ?
#9 Updated by Fabrice Barconnière almost 10 years ago
- Target version changed from Mises à jour 2.3.11 to Mises à jour 2.3.12
Que fait-on de cette demande ?
#10 Updated by Fabrice Barconnière almost 10 years ago
- Due date deleted (
11/15/2013)
#11 Updated by Joël Cuissinat almost 10 years ago
- Due date set to 11/08/2013
- Status changed from A étudier to Résolu
- Target version changed from Mises à jour 2.3.12 to Image iso 2.3.11 minimale
- % Done changed from 0 to 100
Demande bloquante pour #6773
#12 Updated by Fabrice Barconnière almost 10 years ago
- Status changed from Résolu to Fermé