Hi, 21.06.2009 16:56, Kern Sibbald wrote: > On Sunday 21 June 2009 15:34:20 Dirk H Bartley wrote: >> On Sun, 2009-06-21 at 14:43 +0200, Kern Sibbald wrote: >>> Hello, >>> >>> On Friday 19 June 2009 17:04:50 Dirk Bartley wrote: >>>> Greetings >>>> >>>> I'd like to start a project to create a page that would allow a user to >>>> create filesets with a gui in bat. In order to do this, I would need >>>> some changes to the director and possibly to the file daemon. >>> I think this would be a great project. It is probably a bit overdue, and >>> I like starting with something a bit smaller than the whole conf file. >> Smaller bites are better. :) >> >>>> I would like to have the ability to query the director for the current >>>> state of files on a file daemon. Not sure exactly what something like >>>> that would look like, but possibly something to the effect of >>>> >>>> .queryfiledaemon client=hostname-fd directory=/etc/init.d >>>> >>>> which would return the current contest of the /etc/init.d directory on >>>> the client client=hostname-fd (obviously :-) >>> Well, essentially, "estimate" does this, but I think for your purposes it >>> will need to be enhanced, and possibly even turned into a .estimate to >>> get a more machine readable format. >> I'm okay with just about any syntax. >> >>>> I'm hoping that I could request a modification like that so that I >>>> could begin to work on a new page. We may have to take into >>>> consideration a command to request roots. So for windows it could >>>> return c:/ d:/ .. .. >>> I believe most of the mechanisms we need are already in place. It is >>> just a question of understanding the whole "page" you want to create so >>> that we can be sure to design in the necessary capabilities from the >>> beginning -- even if we don't implement everything from the beginning. >>> >>> Can you be just a bit more explicit what the page will look like? >> My thoughts were of using the restore browser as a starting point. This >> new fileset interface would not need the jobs widget or the versions >> widget. The work done to make it so that there are black check marks >> for explicitly included and grey check marks for included by being a >> subdirectory should be useful. >> >> I'd want to start out with making it be able to create a fileset from >> scratch. Then later .. .. work toward some mechanism of parsing >> existing fileset resources to prepopulate when opening.
Something I thought about recently :-) My idea was a way to create a fileset in the DIR through the bconsole API, and the ability to (later) add data to existing configuration files. The latter is probably a hard tsk, given the ways you can include configuration files... Imagine there was a bconsole command 'new fileset name= contents=', which injected a new fileset. That fileset would, initially, be empty. Verification that this fileset does not yet exist would be required, of course, and probably a fileset would need a flag "volatile" or something - but that's low-level technology, so I'm not too interested in it :-) Populate the fileset with some initial data, like 'File = /' and options to not descend into any subdirectory. Now, similarly, create a new client and job resource, link them all together, run an estimate, and you've got the list of top-level directories and files. Add commands 'modify fileset|client|job', finally 'dispose fileset|client|job' which would delete unsaved resources, and 'store fileset|client|job'. Actually, as those commands would be unwieldy, the dot-command form might be more suitable. Anyway, using this approach, we no tonly get the tools to walk through a clients filesystem and collect information, but also the needed infrastructure to manage all the configuaration. >> The difficult part I think will be adding an options. Where the user is >> given the ability to add the many options that are available in the >> interface. > > I don't think that will be very hard. You just need to put up a panel that > has all possible options, and be able to get a status of them all so that you > can show the user what is and is not set, then let him/her choose. I even think that, for a GUI, a fileset editor does not need to handle all the options - the regex stuff, for example, is most useful for admins used to command line usage. A GUI-guy [ ;-) ] would not want those but would probably be satisfied with a fixed exclude list. > It seems to me that the first step would be for me to provide you some > interface to explore the files on a client machine. Yup, but make it so that it can be used for later, more interesting, use :-) > At the same time, you can be refining your browse window, and creating some > sort of option picker. > > Then we can start putting it together, and I can give you an interface to get > to existing FileSets or to create new ones. > > I am not available the first three days of next week because I am presenting > a > Bacula Foundation course. After that is finished, I can look into providing > you some interface. > > For the moment, you could experiment with the "estimate" command and tell me > what you like and what you don't like -- especially with the "listing" > option. > > Preliminary design: > It seems to me that giving you an interface that returns all files and > directories within a specified path would be the first step. > > .ls client=xxx path="yyy" Somehow I get the impression that, internally, this would create a fileset and run estimate on it at the client... > Then we might want to add recursion and wild cards. However, my first > question to you is what do you want the output to look like? My inclination > would be to feed you an "ls -l" output. > > What do you think? Start working on it!!! ;-) Arno > Kern > > ------------------------------------------------------------------------------ > Are you an open source citizen? Join us for the Open Source Bridge conference! > Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. > Need another reason to go? 24-hour hacker lounge. Register today! > http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org > _______________________________________________ > Bacula-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/bacula-devel > -- Arno Lehmann IT-Service Lehmann Sandstr. 6, 49080 Osnabrück www.its-lehmann.de ------------------------------------------------------------------------------ Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org _______________________________________________ Bacula-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
