[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bacula-devel] Leopard & Bacul


I make a few comments below, because it appears that there are a few 
misconceptions of Bacula:

On Tuesday 06 May 2008 02:54:24 Hydro Meteor wrote:
> Hi,
> Sorry it took me a few days to respond to your email. I'm probably one of a
> small few who is using Bacula and Leopard (actually, to be specific,
> Leopard Server -- currently 10.5.1 on Xserve hardware). From my extensive
> testing and documentation, Bacula most definitely does not yet support
> backing up of ACL's on Leopard Server (and very very likely also Leopard).
> From my own documentation, these notes might be helpful for you:
> ---------------------------------------------------------------------------
> Notable Limitations
> Chapter 41 of the Bacula User's Guide states these limitations and concerns
> regarding Data Encryption:
> There is one important restore problem to be aware of, namely, it's
> possible for the director to restore new keys or a Bacula configuration
> file to the client, and thus force later backups to be made with a
> compromised key and/or with no encryption at all. You can avoid this by not
> not changing the location of the keys in your Bacula File daemon
> configuration file, and not changing your File daemon keys. If you do
> change either one, you must ensure that no restore is done that restores
> the old configuration or the old keys. In general, the worst effect of this
> will be that you can no longer connect the File daemon.

I wouldn't call the above a "limitation", rather it is a warning to sysadmins.  
This is something that all backup software faces, but it is unlikely many 
vendors mention this potential problem.

> and
> The implementation does not encrypt file metadata such as file path names,
> permissions, and ownership. Extended attributes are also currently not
> encrypted. However, Mac OS X resource forks are encrypted.
> Bacula's inability to encrypt filesystem metadata

Bacula is completely capable of encrypting filesystem metadata.  However, if 
it does so, you will not be able to restore on a file by file basis, OR you 
must give your encryption key to the sysadm.   We prefer to leave the 
metadata unencrypted so that it can be easily displayed for selection during 
the restore.

> means that Access Control 
> Lists (ACLs) will not be encrypted. This is not imperative considering that
> Bacula does not (yet) support backing up ACLs on Mac OS X Server 10.5
> Leopard.

I am not sure whether or not the ACLs are encrypted (I didn't write that 
particular software).  I seen no reason not to encrypt them, and if they are 
not encrypted, then IMO they should be.

Concerning Mac OS ACLs, Darwin is included in the list of systems for which 
ACLs can be backed up if enabled by the user, so if they are not backed up, 
perhaps you have not properly configured Bacula.

As the bulk of the ACL code is contributed, if for some reason your ACLs are 
not backed up, then you should ask the Bacula users list to have someone test 
it and submit a patch so that it works -- the coding involved is not really 
very difficult.

> ---------------------------------------------------------------------------
> In my notes above, what I am saying is that its not imperative because
> backing up of ACLs by Bacula on Leopard is not possible yet so I'll have to
> live without this but the other facets of Bacula are worthwhile to me. Your
> needs might be different than mine, and thus you may not be able to live
> without Leopard ACLs supported by Bacula.
> To further answer your questions, I'm not at all sure how difficult it
> would be for Bacula to include Apple's implementation of ACLs but I can't
> imagine it being atrocious rocket science because Leopard is now fully
> POSIX compliant and also Leopard is also now fully UNIX [1]. 

As I mentioned above, I suspect this is already implemented and supported.  
This would be a point to bring up on the bacula-users email list, where there 
is surely someone using this feature.

> Nonetheless, 
> Apple might be doing something that is fully within the realm of POSIX
> compliance but which could also be different than how other POSX-based
> systems implement ACLs that are supported by Bacula. This is probably a
> very good question for Bacula's prime maintainer, Kern Sibbald (whom I've
> CC'ed) on this email reply. Note: considering the growth of Apple as of
> late (their recent quarterly earnings last week announced that they have
> sold more Macs since Ronald Reagan was in office in the 1980s), suggests to
> me that Apple and its operating systems such as Leopard are here to stay
> and Apple's Time Machine is surely no Bacula (I require Bacula because its
> open source, portable to other systems and thus the knowledge base is
> highly reusable such that I can run Bacula on Linux variants as well which
> is something I in fact do on a Parallels virtual machine running Debian,
> and I have more control with Bacula and know what's going on plus it
> maintains a robust and organized catalog which I save into a PostgreSQL
> database -- all of which is not possible with Apple's Time Machine).
> Net net: I'd love to see future version of Bacula be capable of backing up
> and restoring Apple implemented POSIX ACLs on Leopard, Leopard Server and
> beyond!

I would too, so please work on getting someone to take a look at it and if 
necessary to submit a patch.

Best regards,


> Best regards,
> Hydro
> [1] http://en.wikipedia.org/wiki/Mac_OS_X
> Leopard is an Open Brand UNIX 03 registered product on the Intel platform.
> > It is also the first BSD-based OS to receive the UNIX 03
> > certification.[33][34]
> On Sat, May 3, 2008 at 11:47 AM, R Hannes Beinert <argovela@xxxxxxxxx>
> wrote:
> > Hello,
> >
> > I've been cruising the Bacula archives to check the status of Bacula's
> > compliance with Leopard's extended attributes & ACLs.  You seemed to be
> > the most interested in this subject, as of several months ago.
> >
> > Could you tell me if anything is being planned to upgrade Bacula's
> > functionality in this respect?  I was unable to find any discussion of
> > this subject on the devel list.
> >
> > Do you have any sense of how difficult it would be to implement?
> >
> > Thanks for your time!
> >
> > Hannes.
> >
> >
> >
> >
> > 
> > _________________________________________________________________________
> >___________ Be a better friend, newshound, and
> > know-it-all with Yahoo! Mobile.  Try it now.
> > http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
Bacula-devel mailing list

This mailing list archive is a service of Copilotco.