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
Demandes liées
Révisions associées
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
Historique
#1 Mis à jour par Daniel Dehennin il y a plus de 11 ans
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 Mis à jour par Emmanuel GARETTE il y a plus de 11 ans
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 Mis à jour par Claude Perrin il y a plus de 10 ans
- Version cible mis à 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 Mis à jour par Joël Cuissinat il y a plus de 10 ans
- Projet changé de Scribe à eole-bacula
- Statut changé de Nouveau à A étudier
- Assigné à mis à Daniel Dehennin
- Début
18/09/2012supprimé
#5 Mis à jour par Cédric Frayssinet il y a plus de 10 ans
En effet, sans chown pas de sauvegarde :/
#6 Mis à jour par Daniel Dehennin il y a plus de 10 ans
- Assigné à changé de Daniel Dehennin à 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 Mis à jour par Fabrice Barconnière il y a plus de 10 ans
- Echéance mis à 08/11/2013
#8 Mis à jour par Fabrice Barconnière il y a plus de 10 ans
- Echéance changé de 08/11/2013 à 15/11/2013
Un paquet sera refait avec ces corrections ?
#9 Mis à jour par Fabrice Barconnière il y a plus de 10 ans
- Version cible changé de Mises à jour 2.3.11 à Mises à jour 2.3.12
Que fait-on de cette demande ?
#10 Mis à jour par Fabrice Barconnière il y a plus de 10 ans
- Echéance
15/11/2013supprimé
#11 Mis à jour par Joël Cuissinat il y a plus de 10 ans
- Echéance mis à 08/11/2013
- Statut changé de A étudier à Résolu
- Version cible changé de Mises à jour 2.3.12 à Image iso 2.3.11 minimale
- % réalisé changé de 0 à 100
Demande bloquante pour #6773
#12 Mis à jour par Fabrice Barconnière il y a plus de 10 ans
- Statut changé de Résolu à Fermé