Re: [Bacula-devel] Feature request - bscan from bconsole

[Graham K. <gr...@eq...>]

On Fri, Oct 09, 2009 at 09:39:55PM +0200, Kern Sibbald wrote:
> On Wednesday 07 October 2009 11:02:23 Graham Keeling wrote:
> > Item  n: Run bscan on a remote storage daemon from within bconsole.
> >   Date:  07 October 2009
> >   Origin: Graham Keeling <gr...@eq...>
> >   Status: Proposing
> >
> >   What:  The ability to be able to run bscan on a remote storage daemon
> > from within bconsole in order to populate your catalog.
> >
> >   Why:   Currently, it seems you have to:
> >          a) log in to a console on the remote machine
> >          b) figure out where the storage daemon config file is
> >          c) figure out the storage device from the config file
> >          d) figure out the catalog IP address
> >          e) figure out the catalog port
> >          f) open the port on the catalog firewall
> >          g) configure the catalog database to accept connections from the
> >             remote host
> >          h) build a 'bscan' command from (b)-(e) above and run it
> >          It would be much nicer to be able to type something like this into
> >          bconsole:
> >          *bscan storage=<storage> device=<device> volume=<volume>
> >          or something like:
> >          *bscan storage=<storage> all
> >          It seems to me that the scan could also do a better job than the
> >          external bscan program currently does. It would possibly be able
> > to deduce some extra details, such as the catalog StorageId for the
> > volumes.
> >
> >   Notes:
> 
> I have added this to the projects file, but with the following reservations:
> 
>   Notes: (Kern). If you need to do a bscan, you have done something wrong,
>          so this functionality should not need to be integrated into the
>          the Storage daemon.  However, I am not opposed to someone
>          implementing this feature providing that all the code is in a shared
>          object (or dll) and does not add significantly to the size of the
>          Storage daemon. In addition, the code should be written in a way such
>          that the same source code is used in both the bscan program and the
>          Storage daemon to avoid adding a lot of new code that must be 
>          maintained by the project.

I have a patch for bacula-3.0.3 that does most of the work for this - it
does queries to the director from bscan if you are running from the storage
daemon, and direct database queries if you are using the standalone bscan.

However, I cannot understand how all the pointers relating to jcrs, dcrs, devs,
and so on in the storage daemon are supposed to be allocated and locked and
how they interact and so on. If somebody could look at this and finish it off
it would be great. I guess the bit to look at is bscan_cmd() in
src/stored/dircmd.c.

Also, I know that git is supposed to be used now, but I don't know how patches
such as this are supposed to be submitted via it.
If things have to be done via git, it would be nice to be told exactly what
git commands I need to run to do the equivalent of submitting a patch.