On Sunday 29 March 2009 21:30:14 Dan Langille wrote:
> Phil Stracchino wrote:
> > Scott Barninger wrote:
> >> Kern and I have had some offline discussion previously on this subject.
> >> The current RPM build offers 2 options, one to place files with LSB
> >> compliance and a second to place files as Kern has advocated and which
> >> is how Bacula Systems is delivering binaries.
> >> My 2 cents worth is that packages published by the project on
> >> sourceforge should respect LSB and distribution (linux or BSD)
> >> guidelines. The advantages of this approach are:
> >> 1. we don't get emails from people complaining about file placement
> >> 2. we don't suffer hesitation from people who are strongly in favor of
> >> LSB 3. it creates a differentiator for Bacula Systems.
> >> On Sunday 29 March 2009 11:03:32 am Dan Langille wrote:
> >>> Discussion trimed to devel & beta
> > FWIW, I have *always* used the /opt/bacula layout. It puts the entire
> > Bacula installation in one place separate from everything else on the
> > machine, and makes it trivial to (for example) install Bacula on an
> > otherwise bare disk booted from a CD, then do a full system restore
> > without overwriting any active files. One could, for instance, boot
> > from a Knoppix CD and copy /opt/bacula from an NFS share, or mount it
> > from a USB stick (as we were discussing recently).
> > The problem with slavish adherence to things like the LSB is that it
> > isn't always the best solution for everything.
> > "Our corporate policy says we always do this."
> > "That's fine, but this won't work if you do that."
> > "But corporate policy says..."
> > One size does not fit all. Standards are great, but sometimes you have
> > to recognize that there are special cases for which the standard is not
> > the best solution, and that sometimes trying to make them conform to
> > "the standard" is actively harmful. The trick is to recognize the
> > occasions upon which applying "the standard" is not appropriate.
> When it comes to the official port/package/whatever of a given OS, it
> must adhere to the standards set by that OS. Hence, I can't see the
> FreeBSD port doing anything other than what it's doing now.
> I don't think anyone is suggesting otherwise.
Yes, I am suggesting that all distros should use the Bacula recommended
configuration. We can then automate a lot of nice stuff.
> I do see the benefits in providing a solution which contains a
> completely self-contained installation of Bacula. I'd welcome someone
> working on that for FreeBSD.
> FWIW, in case, if I were recovering a failed box on new hardware, my
> first step would be installing the OS, then Bacula, and going from there.
Unfortunately, life is generally much more complicated than that -- first, how
do you recover Bacula? Without your bacula-dir.conf, bacula-sd.conf,
bacula-fd.conf files, plugins, modifications to scripts such as the
autochanger, ... you will have problems. The new Bacula proposed
installation permits very easy restoration of all that.
On my system, the backup of the catalog, *all* bacula files, and a snapshot of
my hard disk configuration are all done in one simple script -- I don't have
to worry about missing a file because the install has put files all over the
place. As I say, it is for each to choose ...