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.

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

Reply via email to