BackupPC

> BTW Craig, had you decided to change that variable like we briefly talked
> about? It will have to pass it to Samba as $PASSWD, since that's what it
> expects, but I think something like $BPC_SMB_PASSWD would be better. That
> way I could look for $BPC_DB_PASSWD for the database.

Yes, I agree.  I'll change the password environment variable to
BPC_SMB_PASSWD.  It will default to PASSWD if BPC_SMB_PASSWD
doesn't exist.

> Another BTW Craig, I can't use NULLs in "client" for global config items as
> you had suggested, since "client" has to be part of the primary key for the
> Config table. So I'll use blanks instead of NULLs for any of "client",
> "group", "subscript", or "key" that doesn't make sense for a particular
> item.

Ok.

> > - Add/remove/config clients from the config page
> 
> As long as all of the backend work by this is done by BackupPC::Lib methods,
> there should be no problem. We may need to do some shuffling in order to get
> all our stuff to work together. For instance, modifying the text config
> files should probably go in BackupPC::Config::Text, instead of directly in
> ::Lib.

Add/remove/config clients via CGI will be very useful.  This allows a
complete self-service setup for BackupPC.  Users could simply add their
machine, pick a config group (eg: WinXX desktop), change settings they
care about, and they are done.

> > - Logging, if any, to the database
> 
> I will be storing backup and restore info to the database. As far as
> logging, I don't even know where exactly that's handled right now. It's
> really a separate issue, and we probably wouldn't want to put logging stuff
> in the config modules, but at the same time the two should use the same DB
> connection. (Actually, I am storing the dbh in the ::Lib object, so we'd
> just maybe have to change where the dbh is created).

The various log files should remain separate.  They're compressed and
often quite large, so there's little benefit putting them in a database.

The best candidates for other data to move into the database are the
"backups" and "restores" files, per PC.  All I/O to these files is
through simple routines in Lib.pm, so it shouldn't be too hard to
add them to sql after the config stuff is done.

Craig

> The best candidates for other data to move into the database are the
> "backups" and "restores" files, per PC.  All I/O to these files is
> through simple routines in Lib.pm, so it shouldn't be too hard to
> add them to sql after the config stuff is done.

I agree; in fact, since it is so trivial, and the field names are already
neatly stored within the object, that's what I'm working on first. :-)
(Gotta build my confidence for the trickier stuff!)

toby

> I agree; in fact, since it is so trivial...

Well, the part that is not completely trivial is that currently
the upper level code (eg: BackupPC_dump) reads and writes the
entire table to add or delete a backup.  Ugh.  This code should
move into the library, with routines like BackupTableInsert() and
BackupTableDelete() or something equivalent.

Craig

> Well, the part that is not completely trivial is that currently
> the upper level code (eg: BackupPC_dump) reads and writes the
> entire table to add or delete a backup.

Well, what I'm doing there is seeing which #'s for that client are already
in the database, inserting the ones that weren't there, and deleting the
ones that aren't in the hash-array that gets passed to it. It may not be the
best way in hindsight, but it follows my "change as little as possible for
now" technique.

toby