Menu
▾
▴
[BackupPC-devel] Re: BackupPC_Admin changes & roadmap
|
From: <cba...@us...> - 2003-07-13 01:44:28
|
> > Jason, I'd really like to include this in v2.1. But I would
> > like to base this on Config meta data, rather than hard code
> > each editable field. I haven't devised the format of the
> > config data, but we can come up with something pretty easily.
> > If we devise a format for the config meta data, would you
> > be willing to port your config editor to use this format?
>
> Craig, I'm very much willing. ;)
>
> > The Config meta data is also useful for future support of
> > an SQL backend.
> >
> > Compound variables (eg: $Conf{BackupFilesOnly}) are a little
> > tricky; we should discuss which approach is best.
> >
>
> Yes indeed. Just give the go signal and I'll find time for it.
>
> Thanks and looking forward to make sense contributions to BackupPC.
Great.
What I was thinking was we would build a simple meta data description
of which fields are editable and how they behave.
Here are some design issues:
- It should be easy to add new configuration variables to the
editing screens.
- Some values can be set on a per-PC basis, while other values
only take effect in the main config.pl file. For values that
can go in either place we need a way for the administrator to
set values either in the main config.pl file or on a per-PC
basis. It has to be clear what they are doing.
- (Advanced issue) When we upgrade the backend to use SQL we will
actually support one more class of config files (in addition to
per-PC and global). This gives three levels of config files:
- per PC: overrides any per-group and global settings.
- per group (eg: win-desktop): overrides global settings.
- global: master settings and defaults.
Currently the config editor should allow admins to edit the master
settings and admins and users can edit the per-PC settings. Later,
when we add groups, admins should also be able to edit group settings.
- We should only place values in the per-PC config.pl that are
different from the main config.pl. This allows an administrator
to set site-wide settings in the main config.pl file that aren't
overridden by the per-PC settings. It would be confusing if you
changed just one value in the per-PC config.pl file, only to have
all the master config.pl file settings replicated. There are two
choices:
- Currently you have a Default button that resets the value
to the master value. We can then only write per-PC config
values that are different from the master value.
- Or, instead of the default button, we could have a checkbox.
Selecting or deselecting the checkbox controls whether that
value is written to the per-PC config file. Whenever you
edit the value the checkbox is automatically set. Whenever
you deselect the value the text box is set to the global
value.
I prefer the latter approach since it is more explicit.
- Config values should be arranged by logical groups, eg:
Server configuration, per-PC settings etc, similar to how
you have done in your v1.5.0 work.
- It would be nice if the XferMode-specific settings only appeared
based on the XferMode. (eg: the Smb settings only appear when
XferMode is "smb" etc.) This might mean we should use some
javascript to submit and redisplay the page whenever the XferMode
is changed.
When an admin is editing the master config.pl values all settings
should appear: the XferMode-specific behavior should only be for
per-PC config editing.
- Some values are passwords, so they should be displayed with
password input boxes.
- We need to support i18n for the strings that are displayed (banners,
prompts etc). There will be a significant translation effort, but
as a start we can put the correct structure in place an at least get
English right.
- Some basic error checking would be nice, but let's keep it
simple. Making this flexible is difficult. Hardcoding some
error checking is ok.
- The per-PC config editing should be accessible from the PC CGI page.
- Changes to config settings should be logged in the log file.
- Administrators should be able to edit everything that is editable.
Users should be able to edit some things (per-PC settings).
Moreover, we should have a config parameter that allows the
administrator to specify a reduced set of parameters that
a user can edit, eg:
$Conf{CGIUserConfigEdit} = qw(
FullKeepCnt
IncrKeepCnt
BackupFilesOnly
);
- We need (somehow) to support some of the more complex data
types. For example, WakeupSchedule is an array of numbers,
DHCPAddressRanges is an array of hashes, BackupFilesOnly
is a hash of arrays. This is the most difficult area,
and it might be ok if we do some hardcoding here.
We're not trying to develop a fully-featured and flexible
editing system. What we're looking for is something that
works well and is extensible as new config parameters are
added.
Here's an example of what a menu definition might look like.
In one big data structure we define the layout of the edit
page. We could add one more layer for multiple edit pages,
but a single edit page is probably ok for now:
my @MenuDef = (
{
# banner text; not editable
name => 'GeneralServerConfig',
type => 'banner',
},
{
name => 'WakeupSchedule',
type => 'numeric array', # not sure if this is best.
# this would mean a comma
# separated array in one text
# box
},
{
name => 'MaxBackups',
type => 'integer',
},
{
name => 'MaxPendingCmds',
type => 'integer',
},
#
# and lots more
#
#
# Per-PC config values
#
{
# banner text; not editable
name => 'GeneralPerPCConfig',
type => 'banner',
},
{
name => 'XferMethod',
type => 'radio',
values => [qw(smb tar rsync rsyncd)],
perPC => 1,
},
{
name => 'SmbShareName',
type => 'text',
perPC => 1,
xferDepend => 'smb', # only appears if XferMethod is 'smb';
# but always appears for master edit
},
{
name => 'SmbShareUserName',
type => 'text',
perPC => 1,
xferDepend => 'smb', # only appears if XferMethod is 'smb'
# but always appears for master edit
},
{
name => 'SmbSharePasswd',
type => 'password',
perPC => 1,
xferDepend => 'smb', # only appears if XferMethod is 'smb'
# but always appears for master edit
},
{
name => 'BackupFilesOnly',
type => '???', # this is a compound type; don't know
# what to do here
perPC => 1,
},
{
name => 'BackupFilesExclude',
type => '???', # this is a compound type; don't know
# what to do here
perPC => 1,
},
#
# and lots more
#
);
So in one data structure we can describe the entire structure of
the edit screen.
The code would simple pass through the array and emit the correct
HTML. On Submit it would make the necessary updates.
All the strings to display would come from the language specific strings.
For example, the english text for the banner names would be set in
en.pm as:
$Lang{ConfigEditBanner_GeneralServer} = 'General Server Configuration';
$Lang{ConfigEditBanner_GeneralPerPC} = 'General Client Configuration';
The prompt text for each parameter would also come from $Lang, eg:
$Lang{ConfigEditParamPrompt_MaxBackups} = 'Max backups';
The help text would be implenented as you have done, or otherwise
point to the on-line documentation (although it refers to the perl
config.pl syntax, which would be confusing for users).
By the way, the configure.pl script contains code for re-writing
config.pl files.
How does this sound as a basic architecture? Anyone should submit
comments now before we lock things down.
I'll think a little more about the CGI host editing and new host features
and get back to you on that. Having a full "self-service" feature so
users could add their own hosts would be great.
Craig
|