On Wednesday 14 September 2005 05:59, Aleksandar Milivojevic wrote:
> Kern Sibbald wrote:
> > As far as I know, this is not a bug with Bacula, and there is nothing I
> > can do to fix it. Bacula does not restore file permissions with
> > user/group names, but rather uses the Ids. As noted in the document, if
> > you try to restore files to a different system with a different
> > /etc/passwd configuration, your permissions are going to be all screwed
> > up. This is, in fact, what happens when you try to do a restore on an OS
> > booted by a non-Bacula rescue disk.
> >
> > I don't think I am wrong in what I say above. However, if for some
> > reason, I am, someone is going to have to show me the details of how one
> > can do a correct restore without the correct /etc/passwd ... files.
>
> It is possible to correctly restore even with /etc/passwd (and/or
> /etc/group) file completely missing from the system. What for example
> if I delete /etc/passwd by mistake? Even pre-historic Unix dump/restore
> commands can do that. So yes, it is an issue with Bacula if it can't
> restore ownerships and permissions to their original (numeric) values.
As I previously mentioned, this is exactly what Bacula does -- it restores
owenerships and permissions to their original numeric values.
> You have UID, GID, and file mode (permissions). Simply restore them to
> their original values.
It does that.
> You do not need /etc/passwd file for that.
The code internal to Bacula does not use the passwd/group files except to
converti uid and gids to output for printing.
> Actually, for bare metal restores, you want to completely ignore
> whatever bacula-fd sees as /etc/passwd file (since that is not same
> /etc/passwd file as the one system will use after restore is done, and
> system booted from restored file systems).
>
> /etc/passwd and /etc/group files contain only relation between symbolic
> user and group names and UID and GID numbers.
If I am not mistaken, this is a bit of a simplification of what actually goes
on.
>
> User and group names are ment only for human consumption (or in other
> words, so that "ls -l" printout is readable by humans), kernel does not
> know anything about them, and they do not exist in file system's metadata.
I am probably wrong on this, but it is my understanding that ACLs are based on
userids and groups rather than the numeric values.
>
> Kernel works with UID and GID numbers, and that is the information that
> is stored on file system (so basically, that is the information that
> should be restored to its original values)
As I have said at least 3 times, this is exactly what Bacula does.
You haven't offered any reasonable explanation that would lead me to believe
that Bacula is doing something wrong. Please be specific and point to the
broken code, or submit a patch. This way we could resolve the problem.
Personally, I suspect that for a full bare metal restore, which I have done a
number of times on a standard RH rescue disk, the file ownerships will appear
to be screwed up after the restore as long as one is booted into the rescue
system. Which may have been what you saw. Once one boots up the restored
system, the ownerships should take on a normal appearance. For ACLs (and
SELinux), I'm not sure though. The other possibility is that you were not
running the FD as root.
--
Best regards,
Kern
(">
/\
V_V
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
