Project

General

Profile

Anomalie #4085

Scribe 2.3 problème de montage bacula

Added by Nicolas ROBIN over 8 years ago. Updated over 7 years ago.

Status:
Fermé
Priority:
Normal
Assigned To:
developpeurs_eole
Category:
-
Start date:
Due date:
11/08/2013
% Done:

100%

Spent time:
Distribution:
EOLE 2.3

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

Related to python-pyeole - Anomalie #2614: au montage (USB par exemple), chown -R du point de montage Fermé 12/16/2011
Related to eole-bacula - Anomalie #6773: La commande baculamount.py -t ne donne plus d'informations utiles. Fermé 12/13/2013

Associated revisions

Revision 849804da (diff)
Added by yllen over 8 years ago

try to fix - see #4085

git-svn-id: https://forge.glpi-project.org/svn/ocsinventoryng@141 521019e7-676f-4c92-9f5a-82357c860469

Revision 917d0da5 (diff)
Added by Daniel Dehennin over 7 years ago

« 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

Revision 7e97737c (diff)
Added by Benjamin Bohard over 7 years ago

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

Revision d70c919e (diff)
Added by Benjamin Bohard over 7 years ago

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 over 8 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 over 8 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 over 7 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 over 7 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 over 7 years ago

En effet, sans chown pas de sauvegarde :/

#6 Updated by Daniel Dehennin over 7 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 over 7 years ago

  • Due date set to 11/08/2013

#8 Updated by Fabrice Barconnière over 7 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 over 7 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 over 7 years ago

  • Due date deleted (11/15/2013)

#11 Updated by Joël Cuissinat over 7 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 over 7 years ago

  • Status changed from Résolu to Fermé

Also available in: Atom PDF