[clue-tech] Multiple system backups

[William]

David L. Anselmi wrote:

> chkconfig seems to rely on header comments in the init.d scripts.  So 
> if you have a daemon that chkconfig doesn't handle the magic may be 
> missing from its script.  I would guess that service(8) also has some 
> configuration info somewhere and that adding a daemon to its control 
> is easily done.

That's cool.  I had peeked into the aforementioned files and even 
considered writing my own service config files, but decided against -- 
it was quite messy in there when I was reading through existing files as 
examples (maybe I just have bad examples, if you find them easily 
comprehensible).  :)  You're absolutely right, it can be done, but I 
also wanted to address this problem:  "Most INSTALL/HOWTO documents that 
come with packages (justifiably) make no mention of service or 
chkconfig."  At best, the only reference I usually encounter to boot-up 
hooking are instructions to manually add entries to the rc.local file.  
As part of the general mass myself, I believe it safe to assume that 
most people don't write their own service config files for new 
services.  It struck me as an opportunity to fill that void by providing 
a simple solution for those interested in "easily adding ZZbackup.cron 
to their existing solution with minimal effort in the broadest possible 
target environment."  I could be wrong in my approach, but it seems easy 
to me in the general case.  :)

> The Debian package that contains service(8) is sysvconfig.  Its 
> sysvconfig(8) seems similar to chkconfig but Debian doesn't seem to 
> have a package that provides chkconfig.  No packages depend on 
> sysvconfig so it is only installed if you specifically ask for it.  
> (Only 84 systems use it regularly: 
> http://popcon.debian.org/source/by_inst.)
>
> And even though chkconfig isn't packaged, it would be easy enough to 
> install it from source (which might also be the case for service(8) on 
> Solaris, IRIX, AIX, ...)  My comment wasn't so much to point out a 
> weakness in portability as to point out an assumption you had made and 
> that some dependency info is missing from your install instructions. 
> (Leaving out a copyright and license statement might be considered a 
> weakness).

Good information.  You're right, I assumed that service was always 
available based on my limited Linux experience (Red Hat systems only).  
I do hope that by providing an alternative now, people won't be 
affronted by this assumption, but will take advantage of service only 
where it is available and use the alternative where necessary.  In some 
cases, like mine (because I'm too lazy/whatever to integrate new daemons 
into service), it may be beneficial to use both techniques together.

Copyright or license statements don't strike me as warranted on this 
project.  After all, it's just a cron job.  If its scope grows beyond 
that, then I'll be guilty of code-creep.  :)

> That's not meant as a criticism--your script is an interesting 
> discussion piece.  But if you really want people to consider using it 
> you might look at how other, similar, GNU packages are put together.

Please keep the criticism flowing; criticism isn't inherently bad when 
it is visibly justified.  Dialog like this helps everyone grow 
(especially me).  I'm honored that you encourage me to compare my code 
to GNU packages, though that would probably be outside the scope of this 
project.  I may be making it look or sound fancy, but -- as before -- 
it's just a cron job; a slightly enlightened file copy and compression 
task.  :)

Thank you, truly, for all feedback.  This experience is beneficial.
_______________________________________________
CLUE-tech mailing list
CLUE-tech at cluedenver.org
http://cluedenver.org/mailman/listinfo/clue-tech