Re: Strategy for "one-off" tasks

[David Douthitt]

On Tuesday, July 15, 2003, at 09:17  AM, Ted Zlatanov wrote:

> On Mon, 14 Jul 2003, ssrat@mailbag.com wrote:
> > My current thinking is to do this with one or two hidden files - an
> > inversion of the one-off process listed earlier:
> >
> > classes:
> >
> >    DoUpdate = ( FileExists(/var/cfengine/.update) )
> >    AlwaysUpdate = ( FileExists(/var/cfengine/.update-always) )
> >
> > shellcommands:
> >
> >    DoUpdate::
> >      "apt-get -q -y update" define=updatedone
> >
> >    AlwaysUpdate::
> >      "apt-get -q -y update"
> >
> >    updatedone::
> >      "rm -f /var/cfengine/.update"
>
> Why not use files to mark the *end* of the update, and tell cfengine
> to run DoUpdate actions by defining the DoUpdate class externally?
> Then you can just check the date of the .updatedone file in the
> example below to find the date of the last completion.  With your
> method, the absence of the .update file doesn't tell you when the
> update completed.
>
> classes:
>
>    AlwaysUpdate = ( FileExists(/var/cfengine/.update-always) )
>
> shellcommands:
>
>    DoUpdate||AlwaysUpdate::
>      "apt-get -q -y update" define=updatedone
>
>    updatedone::
>      "touch /var/cfengine/.updatedone"

That is an intriguing idea.  What I would be doing is trying to update 
certain systems continually and automatically, and then rolling the 
changes out to other more critical systems after a period of stability 
has passed.

WHile we're discussing it - why not write your code like this instead?

classes:

    AlwaysUpdate = ( FileExists(/var/cfengine/.update-always) )

shellcommands:

    DoUpdate||AlwaysUpdate::
        "apt-get -q -y update && touch /var/cfengine/.updatedone"

David Douthitt
david@douthitt.net
UNIX SysAdmin - HP/UX, UnixWare, Linux
LPIC-1, Linux +