>>>>> On Mon, 3 Mar 2008 11:48:37 +0100, Kern Sibbald said: > > Hello Scott, > > I've copied the bacula-users list because some people may not be aware of the > problems they are getting themselves into using *standard* packages to > install Bacula. > > I *strongly* recommend that we completely reconsider the package directories > that we use. The current way of installing Bacula by packages is *very* far > from optimal. Let me explain ... > > There are standards such as FHS, and these are good and useful for most > programs, but they really do a big disservice to Bacula users when we are > dealing with recovery. If you spread the Bacula installation all around your > computer filesystem as most packages do and as the standards specify, and > your system is a server and the server goes down (loses the harddisk), you > will find it next to impossible to restore that server -- very few people > think about this. What I am saying here applies to a Bacula server > (Director, SD) and not clients. > > A much better scheme for installing Bacula on a server is outlined and > recommended in the manual, and that is to install *everything* (except > perhaps the man pages) either in a single directory or under a single unique > directory. This allows the smart sys admins to backup a single directory > along with their nightly catalog backup, and thus have in hand a single bsr > file that will recover not only their catalog, but all their configuration > files (critical for the Director, and important for the SD) as well as all > the Bacula binaries, which in the future will include plugins required for > restore.
Something I don't understand about this approach -- how do you restore this single directory before you have restored a working Bacula installation that can read the bsr? If you do it using a recovery disk, then you'll need to put all the critical files on that disk anyway. You can also include the Bacula rpms on the recovery disk, to allow them to be reinstalled on the server or on a new server. The plugins should also be installed from rpms. If you do it by reinstalling the OS from normal distro media, then you can also reinstall Bacula from rpms on a CD. __Martin > > Now there could be several choices according to your preferences of how to > install Bacula in a single directory (or under a single directory). On some > systems, this may be /var/bacula, on others it might be /opt/var/bacula, and > after that, you might choose to install *everything* in /var/bacula, or you > might prefer to > have /var/bacula/bin, /var/bacula/scripts, /var/bacula/plugins, ... > > My point is not to try to dictate the exact structure, but to guarantee that > if you backup a single directory, you will get *everything* of importance > that Bacula needs to be restored. Obviously you can also > have /var/bacula/tmp and /var/bacula/working, which you might want or not > want to exclude from the backup. However, the worst case would be to backup > Bacula from a list of files or by specifying each file in the FileSet > include, because if you do an upgrade and we add a new critical file or > someone adds a plugin, then you will find yourself with a *much* bigger job > to get a server backup and running. > > Obviously there are other techniques for dealing with this problem (hot > spare), but IMO, for all Bacula installations, the Bacula files should be > placed in Bacula's own single directory or single directory tree as I have > described above. > > This is something that I would like to see us switch to doing with our rpm > releases, and we would allow users to specify the base structure (a single > directory or a single tree), but if they want to start moving files all over > the place, that IMO should be left to the user to maintain his own spec files > possibly based on ours. > > Best regards, > > Kern > > > > On Sunday 02 March 2008 20.06:43 Scott Barninger wrote: > > FYI this offline conversation... > > > > -------- Forwarded Message -------- > > From: Scott Barninger <[EMAIL PROTECTED]> > > To: Bruno Friedmann <[EMAIL PROTECTED]> > > Cc: Kern Sibbald <[EMAIL PROTECTED]> > > Subject: Re: bacula : about the bacula.spec form rpms > > Date: Sat, 01 Mar 2008 06:55:49 -0500 > > > > Hello Bruno, > > > > I will look at implementing this. > > > > On Sat, 2008-03-01 at 11:55 +0100, Bruno Friedmann wrote: > > > Hi Scott, > > > > > > With an increasing number of customers using bacula, I'm really > > > interesting into one or two piece of change in the bacula spec. > > > > > > The only real annoying thing is that script_dir is hardcoded to the > > > /etc/bacula which is the old "wrong" debian way to put script. > > > > > > Normally I think it's place should be under /usr/lib(64)/bacula ? > > > > Yes, there was some discussion of this back when we changed directory > > locations for FHS compatibility. /etc/bacula isn't really "correct" > > just traditional for bacula. > > > > > I've made some try yesterday, modifing the bacula.spec. And it would be > > > quiet easy to had a build_script define that can change with the > > > configure. > > > > Yes it would be relatively easy for me to add a build time switch to > > alter that location. Having a "build_fhs" define could cause it to be > > set to %_libdir/bacula. > > > > > I understand that would break old install. I'm looking a way to prepare > > > futur and new installation. > > > > > > Perharps I should prepare my own packapes branch to avoid conflict, did > > > you have a trick to add for example a -ioda(0-9) extra release tag (I'm a > > > bit new to rpmbuild :-) ) > > > > I recommend not messing with the release tag. It was only ever meant to > > be a number. rpm would interpret -b1 as "newer" than -a5. > > > > > I've the habit to use also this option during configure : > > > > > > > > > ./configure \ > > > --prefix=/ \ > > > --exec-prefix=/usr \ > > > --sbindir=/usr/sbin \ > > > --sysconfdir=/etc/bacula \ > > > --libexecdir=/usr/lib64/bacula \ > > > --datadir=/usr/share/bacula \ > > > --with-working-dir=/var/lib/bacula \ > > > --with-scriptdir=/usr/lib64/bacula \ > > > --with-pid-dir=/var/run/bacula \ > > > --with-subsys-dir=/var/run/bacula \ > > > --enable-ipv6 \ > > > --enable-largefile \ > > > --enable-smartalloc \ > > > --with-gnu-ld \ > > > --enable-conio \ > > > --with-libiconv-prefix \ > > > --with-libintl-prefix \ > > > --with-gettext \ > > > --with-tcp-wrappers \ > > > --with-dir-user=bacula \ > > > --with-dir-group=bacula \ > > > --with-sd-user=bacula \ > > > --with-sd-group=bacula \ > > > --with-fd-user=root \ > > > --with-fd-group=bacula \ > > > --with-sbin-perm=0754 \ > > > [EMAIL PROTECTED] \ > > > [EMAIL PROTECTED] \ > > > > This should be easy too. > > > > > --with-smtp-host=exchange.ultim.ch \ > > > --with-x \ > > > --with-python \ > > > --with-openssl \ > > > --with-mysql \ > > > --enable-build-dird \ > > > --enable-build-stored \ > > > --disable-batch-insert \ > > > > > > and I usually place some gcc optimisation corresponding to the arch of > > > the cpu something like that > > > > This is possible too. But if you use it you must be complete because it > > will cause rpmbuild not to read the default macros. > > > > > # GCC optimize for Intel () ... > > > # export CFLAGS="-O3 -msse -mmmx -march=x86-64 -mtune=nocona > > > -funroll-loops -mfpmath=sse -g -pipe -ffast-math" # export CFLAGS="-O3 > > > -msse -mmmx -march=pentium4 -mtune=pentium4 -funroll-loops -mfpmath=sse > > > -g -pipe -ffast-math" # export BOOT_CFLAGS="-O3 -march=pentium4 > > > -mfpmath=sse -pipe" > > > # export CXXFLAGS="-Os -march=pentium4 -mfpmath=sse -pipe > > > -mpreferred-stack-boundary=4" > > > > > > > > > # GCC optimize for AMD64 () > > > export CFLAGS="-O3 -msse -mmmx -march=x86-64 -mtune=k8 -funroll-loops > > > -mfpmath=sse -g -pipe -ffast-math" export BOOT_CFLAGS="-O3 -march=x86-64 > > > -mfpmath=sse -pipe" > > > export CXX_FLAGS="-Os -march=x86-64 -mfpmath=sse -pipe > > > -mpreferred-stack-boundary=4" > > > > > > # Clean any previous configure or make > > > make distclean > > > > > > make clean > > > # We use the / configuration ... > > > #./configure pentium4-suse-linux \ > > > > > > > > > > > > All of my install work under suse 10.1 / 10.2 / 10.3 and I've got no > > > trouble with them. If you have any remarks or comment, I will be glad to > > > heard them ... > > > > > > > > > I've in my idea box also the use of openbuild.suse.com (this could easily > > > extend the portability of the project) > > > > > > Have an excellent week-end. > > > Regards. > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Microsoft > > Defy all challenges. Microsoft(R) Visual Studio 2008. > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > _______________________________________________ > > Bacula-devel mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/bacula-devel > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Bacula-users mailing list > Bacula-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-users > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
