Distribution EOLE » Commun » eole-bacula

Contexte : SCRIBE-2.2.2 à jour

Dans le cadre d'un remplacement de matériel, j'ai, dans les 15 derniers jours, à 2 reprises, restauré un scribe.
A chaque fois, la démarche a été la suivante :

• mise à jour totale de l'ancien scribe 2.2.2, reconfiguration, reboot
• lancement d'une sauvegarde totale
• installation de la nouvelle machine
• instanciation puis mise à jour, reconfiguration et reboot
  L'ancien et le nouveau serveur sont donc exactement au même niveau de mises à jour.

Ensuite, lancement du script restauration-bacula.sh sur la nouvelle machine.

Le problème :
Sur le nouveau serveur, je constate que seules les acl déjà positionnées à l'install sont présentes.
Par exemple, on retrouve les bonnes acl sur /home/workgroups/commun/logiciels

Par contre, pour un répertoire de classe (nouvellement restauré donc) nommé c63 (et pour lequel je suis certains que des acls existaient sur l'ancien serveur), je n'ai aucune acl positionnée, ce sont donc les droits "standards" qui s'appliquent.

Un getfacl sur le répertoire concerné indique seulement :

1. owner: root
2. group: root
   user::rwx
   group::r-x
   other::---

A l'aide des scripts :

• droits_partage.sh
• droits_user.py
  je réussis à remettre en place des droits corrects.

La première fois que cela m'est arrivé j'ai d'abord cru à une erreur de ma part.
Mais le problème intervient 2 fois sur 2.

En tentant une restauration partielle vers un répertoire de test (/home/test, donc en ext3 et avec gestion des acls activée), je constate exactement le même problème.

J'ai l'impression que les acls n'ont pas été sauvegardées.

J'ai, par acquis de conscience, effectué le test suivant :

• Création d'un nouveau Job de sauvegarde dans bacula-dir.conf
  En voici le contenu :
  _Job {
  Name = "Test"
  FileSet = "FileSetTest"
  Type = Backup
  Client = 127.0.0.1-fd
  Storage = File
  Messages = Standard
  Pool = Default
  Priority = 10
  Write Bootstrap = "/var/sauvegardes/TestBootStrap.bsr"
  RunBeforeJob = "/usr/share/eole/bacula/baculaservices.sh lock"
  RunBeforeJob = "/usr/share/eole/bacula/baculaservices.sh prebackup"
  RunAfterJob = "/usr/share/eole/bacula/baculaservices.sh postbackup"
  RunAfterJob = "/usr/share/eole/bacula/baculaservices.sh unlock"
  RunAfterFailedJob = "/usr/share/eole/bacula/baculaservices.sh postbackuperr"
  RunAfterFailedJob = "/usr/share/eole/bacula/baculaservices.sh unlock"
  }

FileSet {
Name = "FileSetTest"
Include {
Options {
signature = MD5
compression = GZIP
aclsupport = yes
}
Options {
wildfile = "*/.scanned:*"
exclude = yes
}
File = /home/workgroups/c63
}
}_

J'ai ensuite, depuis bconsole, lancé une sauvegarde à partir de ce job.
J'ai restauré dans /home/test en sélectionnant l'intégralité (restore all).

Constat sur les acls :
Seul le répertoire '/home/workgroups/c63' a retrouvé ses acls.
Si je relance une restauration spécifique du répertoire /home/workgroups/c63/travail, aucune acl n'est restaurée.

On dirait qu'en fait, seules les acls du répertoire racine sont sauvegardées et pas celles de son contenu.

Cela est d'autant plus gênant qu'une gestion fine des acls sera perdue en cas de restauration.

Est-ce un bug bacula? Une mauvaise configuration? Une mauvaise utilisation? Je ne sais pas.
Si ce problème ne peut pas être réglé, peut-être pourrait-on envisager une sauvegarde des acls incluse dans un RunBeforJob et gérée par restauration-bacula.sh