[Gllug] Backing up cron

Bruce Richardson itsbruce at uklinux.net
Tue Feb 12 00:48:10 UTC 2002


On Mon, Feb 11, 2002 at 11:15:21PM -0000, Dean wrote:
> No not backing up using cron as google seems to think...
> 
> I'm interested in hearing what other people on list do to backup and
> maintain crontabs on Unix boxes (In my case its Linux, Solaris and
> HPUX.) The ones in work are getting quite large and spread over
> numerous machines so I've got this insane scheme where I either use
> ssh and a separate user account with sudo to get a copy of all the
> crontabs or the sudoed user and gnupg to send an encrypted email of
> them (I like to send the fewest possible bits in plain text) to an
> admin account and get them on to a separate box.
> 
> Once I've got them there I can diff them and if any changes are
> detected leave a mail for the admin (me :)) and check them in to cvs.
> The other possibility is I do a 'push' rather than a 'pull' and use
> something like cfengine to dispatch them.

Don't use cfengine to distribute your crontabs, use cfengine to replace
them.  Oh, and cfengine uses "pull".

Most anything you can do in a cronjob you can do in cfengine.  cfengine
can be configured to behave differently depending on the
hostname/operating system/day of the week etc.  It runs on all the OSs
you mention (and NT).  By sensible use of classes you can represent the
configuration of your entire network in one cfengine script.

cfengine uses a pull method, not a push one.  The most you can do
remotely to a machine running cfengine is make it run cfengine (and pass
it keywords to indicate which of the pre-prepared sets of actions you
want it to carry out).  Here's how I use it:

When I first install cfengine on a new machine I copy onto it a minimal
cfengine script called cfpulldown.sh.  This pulls down the current
cfengine config file from the central server and runs it with an
"update" class, which pulls down all the other config files and scripts
associated with my cfengine set-up, configures the cfd daemon etc.
Then I run the current cfengine with no special classes and it does it's
regular thing.

From then on a cron script runs cfengine on the machine at regular
intervals.  Once a day it is run with the update classname that makes it
synchronise the config.  If I have updated the config on the central
server and want it to take effect before then I run cfrun with the
"update" classname.  cfrun contacts the cfd daemon on each host and
passes it the update classname.  cfengine then runs on the satellite
host and pulls down the new config.

That's a pull distribution system.  All I can do is signal the satellite
hosts to run cfengine.  I can't make cfengine do anything that isn't
in the config file.  It's all encrypted and uses private keys so that
even if someone poisons our DNS they can't feed it a malicious config
file.

Oh, backup: all the config details for the entire network (those that
are managed from cfengine, which is most of them) are in the
/etc/cfengine/cfengine.conf file or in files stored in a directory tree
I created within /etc/cfengine.  So backup is easy.  Distribution is
easy.  And I'm a happy bunny.

-- 
Bruce

I see a mouse.  Where?  There, on the stair.  And its clumsy wooden
footwear makes it easy to trap and kill.  -- Harry Hill
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 261 bytes
Desc: not available
URL: <http://mailman.lug.org.uk/pipermail/gllug/attachments/20020212/65ffbac9/attachment.pgp>


More information about the GLLUG mailing list