Hi Sam,
I am still around and have that code in production at a customer site. It
works but lacks polish however, it has the non-hard coded parsing of the
config.pl that you (if you are so inclined) may be able to integrate with
Josh's Interface code to make it look pretty. If you could take those two,
integrate them together and conform as much as possible to the way Craig
wants the standard, you could be onto something extraordinary
.
If you would like the code, drop me a line and I will send you the latest
version that seems to work with 2.0 and so should be easy for you to get
working with 2.0.2 (which has great new features). Together these could
turn BackupPC into a much easier tool for admins, who are new to Linux, to
get installed and working.
I hope you go for it. I am always willing to lend a hand where I can as
well. I am just setting up another backuppc here (with 2.0.2) so now is a
good time to get my attention
Leon
"Wise men talk because they have something to say.
Fools talk because they have to say something." -- Plato
-----Original Message-----
From: Craig Barratt [mailto:craig < at > atheros.com]
Sent: Tuesday, March 30, 2004 9:15 PM
To: Sam Przyswa
Cc: Craig Barratt; BackupPC List; jm_pernito < at > hotmail.com
Subject: Re: [BackupPC-users] Admin config.pl editing
Sam Przyswa writes:
It's just what we need, the screenshots look great, I got the source
to see the work to do for 2.0.2 compatibility.
I weel tell you more ASAP.
Some more history. Leon Letto funded an earlier effort (ie: paid someone
out of his own pocket) to develop an interface based on 1.5.0. He donated
that code under the GPL. It does work, but is basic and doesn't have the
polish of Jason's GUI. I can forward the code if you want - style-wise it
is pretty different to BackupPC, so it would need a lot of work if you
started with this.
Also, Josh McAllister (in Dec '03) and several other people have expressed
interest in developing a config editor.
Attached are some design notes that I sent last summer.
Craig
#################################################################
To: "jason pernito" <jm_pernito < at > hotmail.com>
cc: backuppc-devel < at > lists.sourceforge.net
From: cbarratt < at > users.sourceforge.net
Subject: [BackupPC-devel] Re: BackupPC_Admin changes & roadmap
Date: Sat, 12 Jul 2003 18:44:12 -0700
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 < at > 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
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial
presented by Daniel Robbins, President and CEO of GenToo technologies. Learn
everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
BackupPC-users mailing list
BackupPC-users < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/
