[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bacula-devel] [Fwd: Re: bacula : about the bacula.spec form rpms]
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
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
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
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.
On Sunday 02 March 2008 20.06:43 Scott Barninger wrote:
> FYI this offline conversation...
> -------- Forwarded Message --------
> From: Scott Barninger <scott@xxxxxxxxxxxxx>
> To: Bruno Friedmann <bruno@xxxxxxxxxxx>
> Cc: Kern Sibbald <kern@xxxxxxxxxxx>
> 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 \
> > --with-dump-email=admin_topd@xxxxxxx \
> > --with-job-email=admin_topd@xxxxxxx \
> 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.
> Bacula-devel mailing list
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.