Anomalie #759
Problème de sauvegarde restauration des acls
100%
Description
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 :- owner: root
- group: root
user::rwx
group::r-x
other::---
- 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
Demandes liées
Révisions associées
Merge runtime-speedup-759.
Fixes #759.
Authors: amberite, mithrandi
Reviewers: mithrandi, exarkun
This provides a substatial speed-up for {set,append}NodeContent() on Firefox.
It also adds nits for these, and a workaround in nit for the fragment nesting
problem.
Ajout de la restauration des acls avec bacula pour Scribe et Horus fixes #759
correction de "baculafichiers.d/fichier.conf" pour la sauvegarde des ACLs FIXES #759
correction de "baculafichiers.d/fichier.conf" pour la sauvegarde des ACLs FIXES #759
move projecttask in planning; fix #759
Historique
#1 Mis à jour par Joël Cuissinat il y a presque 14 ans
- Version cible changé de Mises à jour 2.2.2 - 03 Stable à Mises à jour 2.2.2 - 04 RC
#2 Mis à jour par Joël Cuissinat il y a plus de 13 ans
- Version cible changé de Mises à jour 2.2.2 - 04 RC à 48
#3 Mis à jour par Laurent Flori il y a environ 13 ans
- Statut changé de Nouveau à Résolu
- % réalisé changé de 0 à 100
Appliqué par commit 2dee7a4de12d3a7bc97718cfdd7509ee695bd67e.
#4 Mis à jour par Joël Cuissinat il y a environ 13 ans
- Assigné à mis à Laurent Flori
- Version cible changé de 48 à Mises à jour 2.2.2 - 07 RC
#5 Mis à jour par Anonyme il y a environ 13 ans
Bonjour,
Je constate que la solution retenue a été de créer une sauvegarde/restauration des acls par script.
- Dans le cas de scribe, si la variable home_path a une valeur autre que /home,
getfacl --absolute-names -PR /home > $ACLSAVFILE
sauvegardera home et pas la valeur de home_path.
- Dans le cas d'horus, /home est un lien symbolique vers /data/home
Or, des acls existent également sur d'autres sous-répertoires de /data (/data/minedu notamment). Je pense que les utilisateurs des applications administratives nationales vont vite s'en rendre compte, suite à une restauration.
Il serait donc souhaitable d'effectuer un test sur le module afin de connaître la cible de getfacl, et d'adapter, ainsi, au cas par cas, ce qui sera sauvegardé. Qu'en dites-vous?
#6 Mis à jour par Joël Cuissinat il y a environ 13 ans
- Statut changé de Résolu à Fermé
OK pour aujourd'hui ;)
#7 Mis à jour par Klaas TJEBBES il y a environ 13 ans
- Statut changé de Fermé à Nouveau
- Version cible changé de Mises à jour 2.2.2 - 07 RC à 48
La solution a été trouvée au niveau de la configuration, il faut supprimer la gestion "EOLE" des ACLs en pre-backup.
#8 Mis à jour par Joël Cuissinat il y a environ 13 ans
- Version cible changé de 48 à Mises à jour 2.2.3 - 01 RC
- % réalisé changé de 100 à 80
#9 Mis à jour par Joël Cuissinat il y a presque 13 ans
- Statut changé de Nouveau à Résolu
- % réalisé changé de 80 à 100
Il ne reste plus qu'à tester !
#10 Mis à jour par Jean-Marc MELET il y a presque 13 ans
Testé...et approuvé!
Mais peut-on avoir l'explication exacte de l'origine du problème par curiosité? (comme ça fait bientôt 1 an qu'on la cherche...). Est-ce juste du à un mauvais ordre dans quelques lignes du fichier baculafichiers.conf?
Merci pour la résolution en tout cas
#11 Mis à jour par Joël Cuissinat il y a presque 13 ans
- Statut changé de Résolu à Fermé
- conf-scribe (2.2-eole201~4)
- conf-horus (2.2-eole96~1)