Re: [BackupPC-users] BackupPCd: HOWTO test?

2006-02-14 Thread Craig Barratt
Olivier LAHAYE writes:

 As I'm realy interrested in BackupPCd (to backup openned files on windows), 
 I'd like to test it so I could help debugging.

BackupPCd is under development and I doubt it is ready for
more general use.  Roy could advise.

Also, it does not yet have open file suport for WinXX.

Craig


---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642
___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/


Re: [BackupPC-users] Backup Chunking (was: New user, few questions)

2006-02-14 Thread Carl Wilhelm Soderstrom
On 02/13 07:34 , Craig Barratt wrote:
 Putting perl code in the config file has some drawbacks. First, it won't
 work with the new config editor (but that's not released yet).  Second,
 any code that takes time to execute (eg: contacting a client to list its
 modules) will make the CGI script run slowly since it is read on every
 request specific to that client.

thank God you're sensible about this, Craig. Entirely too many perl mongers
have the idea that just because one can put perl script into a config file,
that it should be done. (Witness the abominable config files for LogWatch).

Other reasons to avoid scripts in config files:
a. it makes the config confusing to read, even for those people who can
write perl
b. it's immediately discouraging to those of us who can't

Thanks again for a sensibly and cleanly designed tool, Craig.

-- 
Carl Soderstrom
Systems Administrator
Real-Time Enterprises
www.real-time.com


---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642
___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/


Re: [BackupPC-users] Backup Chunking (was: New user, few questions)

2006-02-14 Thread Les Mikesell
On Tue, 2006-02-14 at 08:29, Carl Wilhelm Soderstrom wrote:

  Putting perl code in the config file has some drawbacks. First, it won't
  work with the new config editor (but that's not released yet).  Second,
  any code that takes time to execute (eg: contacting a client to list its
  modules) will make the CGI script run slowly since it is read on every
  request specific to that client.
 
 thank God you're sensible about this, Craig. Entirely too many perl mongers
 have the idea that just because one can put perl script into a config file,
 that it should be done. (Witness the abominable config files for LogWatch).

I have to disagree on this one, although in a pure-perl app it
doesn't matter a lot and with a cgi interface you need to know
what executes every hit and what doesn't. MimeDefang is a great
example of where the config file being a snippet of perl allows
the local admin to easily do things no one else had even considered,
something that's impossible if all you can do is set some canned
variables.

 Other reasons to avoid scripts in config files:
 a. it makes the config confusing to read, even for those people who can
 write perl

It doesn't have to be confusing.  I'd rephrase your comment above
and say that just because it can be confusing doesn't mean it
should be.

 b. it's immediately discouraging to those of us who can't

Learning perl will save time for a system administrator. But
you should only need to know it to do things that would otherwise
not be possible at all. 

-- 
  Les Mikesell
   [EMAIL PROTECTED]




---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642
___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/


Re: [BackupPC-users] Backup Chunking (was: New user, few questions)

2006-02-14 Thread Bernardo . Rechea

Les Mikesell wrote:

  thank God you're sensible about this, Craig. Entirely too many perl
mongers
  have the idea that just because one can put perl script into a config
file,
  that it should be done. (Witness the abominable config files for
LogWatch).

 I have to disagree on this one, although in a pure-perl app it
 doesn't matter a lot and with a cgi interface you need to know
 what executes every hit and what doesn't. MimeDefang is a great
 example of where the config file being a snippet of perl allows
 the local admin to easily do things no one else had even considered,
 something that's impossible if all you can do is set some canned
 variables.

I'm of two minds myself about this.

First, it's not just that one can add Perl code to the config file,
it's that it _is_ Perl code already. And that makes for interesting
features that are not possible
in regular config files, like nested data structures. Take for example
something like

$Conf{BlackoutPeriods} = [
{
 hourBegin = 23,
 hourEnd   = 3,
 weekDays  = [1, 2, 3, 4, 5, 6, 7],
},
];

That is a concise, readable (at least for me), and flexible way to express
blackout periods. With
a normal config file, it would be possible to express that, of course, but
it would be much more clumsy.

Then, the possibility of going beyond the mere assignment of variables
gives one
extra flexibility when needed. Of course, in that case you need to know
Perl.

As an aside, there is an even more readable format for config files, YAML
(http://www.yaml.org), which is really not just for that, but is intended
to represent any data structures in a language-independent way. I love it
and use it all the time, but it still is limited to data, not code (and I
would like it to stay that way).

Second, the fact one can add code to a config file doesn't mean I'm for
littering it
to the point of making it an unreadable monster. There should be some
restrain on what one adds to such a config file. For instance, if a
solution to a problem, implemented
this way, proves to work and is sufficiently popular, then it may be time
to consider it
for inclusion in the main code. So then, the possibility of
experimentation, which is
why I've done it that way, is an important reason to have a Perl-code
config file.

  Other reasons to avoid scripts in config files:
  a. it makes the config confusing to read, even for those people who can
  write perl

Out of the box, as originally distributed, config files probably shouldn't
go beyond assigning variables statically, I'd agree with that. But why
unnecessarily limit the extent of customizations that can be done after
installation?

 It doesn't have to be confusing.  I'd rephrase your comment above
 and say that just because it can be confusing doesn't mean it
 should be.

  b. it's immediately discouraging to those of us who can't

 Learning perl will save time for a system administrator. But
 you should only need to know it to do things that would otherwise
 not be possible at all.


I completely agree here. There are always going to be special needs that no
generic setup can acommodate. Knowing how to program in Perl (Perl's my
favorite language, but other dynamic languages may often be just as good
for a particular problem), will make easy thing easy, and hard things
possible, as one of Perl's mottos goes. And having the config file be Perl
makes the solution one step closer to the BackupPC code than it would be
otherwise.

Bernardo




---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642
___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/


Re: [BackupPC-users] $Conf{SendmailPath} is not a valid executable program

2006-02-14 Thread Craig Barratt
dosseh edj  writes:

 My BackupPC's server worked well. But last day, i did'nt start  the
 server due to this message:

$Conf{SendMailPath}=''  '/usr/sbin/sendmail'

 is not a valid executable program. What would be  the problem? Please help.

Your setting of $Conf{SendMailPath} is not correct.

If you have pasted the text correctly, it appears to be set to
something like:

$Conf{SendMailPath}='  '/usr/sbin/sendmail;

instead of 

$Conf{SendMailPath}='/usr/sbin/sendmail';

Craig


---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642
___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/