Re: [BackupPC-users] Backup Chunking (was: New user, few questions)
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)
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)
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] Backup Chunking (was: New user, few questions)
[EMAIL PROTECTED] writes: As you can see, this is going pretty slow on my side, but I'll keep making progress from time to time. I tried to do the easiest thing first, i.e., switching to using rsyncd, instead of rsync, and hardcoding the rsyncd modules in the config file for a particular client, just to see if that approach would work, before commiting to writing code that would compute the rsync modules automatically. But I hit a snag with rsyncd authentication: I'm getting an auth required, but service XXX is open/insecure error. I'm copying some files (would it be better if I attached them?), suitably sanitized, to see if anything rings a bell with somebody that can help me. I don't have much experience with rsyncd, so I'm hoping it'll be obvious to somebody else with more experience. The error means that rsyncd on your client is wide open - no password is required. You can tell BackupPC to ignore that with: $Conf{RsyncdAuthRequired} = 0; But I really don't recommend that. Instead you should configure rsyncd with a password: The client's /etc/rsyncd.conf: gid = users read only = true use chroot = true transfer logging = true log format = %h %o %f %l %b log file = /var/log/rsyncd.log #hosts allow = trusted.hosts hosts allow = IP address of BackupPC server slp refresh = 300 #[Example] # path = /home/Example # comment = An Example # auth users = user # secrets file = /etc/rsyncd.secrets [home_snapshot_set1] comment = someuser's home dir read only = true path = /home_snapshot exclude = /otheruser1 /otheruser2 /otheruser3 [home_snapshot_set2] comment = Everything but someuser's home dir read only = true path = /home_snapshot exclude = /someuser You need to specify secrets file, strict modes = false, and auth users. By the way, Craig may be cringing at the way I'm butchering the config file, and adding all kinds of extraneous stuff. I don't like it myself, but it seemed the quickest way to explore the idea of automatic backup chunking. Any ideas welcome. 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. A better approach is to add new (static) config variables and add the appropriate code to the rsync xfer method. Or you could use some kind of magic string (eg: *) for the rsync share name, and take that to mean use the module list for the rsync share names. 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/