On Thu, Oct 15, 2009 at 03:50:24PM +0200, Ralf Gross wrote: > Graham Keeling schrieb: > > 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 <gra...@equiinet.com> > > > > 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. > > > > If bscan is available from bconsole, why would you ever want to run it as > > a separate, more difficult to use, stand-alone program? > > You can use bscan as stand-alone program without installing and > configure the sd. In a desaster recovery situation this might be > helpfull.
The sd config files are needed for bscan to work. And if you're going to put a program on the storage machine, it might as well then be the storage daemon rather than bscan. ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Bacula-devel mailing list Bacula-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-devel
