help-cfengine
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Application management


From: Allen Bettilyon
Subject: Re: Application management
Date: 25 Mar 2003 16:33:41 -0700

apt is perfect solution for managing both debian and rpm packages.

I am using this on my production servers to keep rpms in sync and
current.  I have written a perl script to marry apt with cfengine.

Essentially, I distribute rpmlist files accross my cluster.  Which is
nothing more than a list of 'should-be' installed rpms.  The script than
figures out what rpms need to be "apt-get installed" and which rpms
should not be there.  

- Allen



On Mon, 2003-03-24 at 15:12, Jamie Wilkinson wrote:
> This one time, at band camp, Paul Dlug wrote:
> >- Package management: what methods are people using to manage FreeBSD 
> >and/or Solaris packages with cfengine? I'd like to use platform 
> >specific packages were possible instead of something like RPM or OpenPKG
> 
> I'm (slowly, i.e. when I get a chance to do some development work) working
> on a patch to cfengine to add a "package:" section, but currently it hasn't
> gone past the design stage and I'm currently to busy to start implementing
> it :(  I want to be able to support RPM and Debian packages, and the plan is
> to be extensible to other package management systems (I have no idea how the
> commercial unices do their package management).
> 
> >- "Undo": how do you gracefully handle the case were a server has been 
> >removed from a group and should no longer have the 
> >software/mounts/configuration needed for that app.
> 
> I try to write my configuration inputs to do the minimum necessary on a
> default installation, then tracking those changes and reverting becomes less
> complex.  It's still hard though -- I think the current solution is to
> handle both the inclusive and exclusive classes and either add or remove the
> configuration, i.e.:
> 
> editfiles:
> 
>    someclass::
> 
>       ... changes ...
> 
>    !someclass::
> 
>       ... negate changes ...




reply via email to

[Prev in Thread] Current Thread [Next in Thread]