On Tue, 2005-03-01 at 14:10, David Douthitt wrote:
> Phil D'Amore wrote:
> > On Mon, 2005-02-28 at 13:27, David Douthitt wrote:
>
> >>There are already tools to manage packages in each environment; cfengine
> >>shouldn't replicate their code.
>
> > Yes but their interfaces are different. If I want to know what version
> > of a package is installed on a Solaris box I'd use something like
> > pkginfo -x. If I want to know on a stock Red Hat box, I'd use rpm -q.
> > Their output is different, and thus slightly different logic to parse
> > that output is required.
>
> That's where the wrapper comes in. Use "PkgInstalled" as a function and
> use "PkgInstalledCmd" as an abstraction. Then you could have this:
>
What do you mean use PkgInstalled as a function. Where?
> linux::
> PkgInstalledCmd = ( ReturnsZero("rpm -q %s") )
>
> solaris::
> PkgInstalledCmd = ( ReturnsZero("pkginfo -x %s") )
>
> > Cfengine needs to be coded to understand the query command's output (or
> > use a generic wrapper as Tim Nelson suggests). That is all I'm saying
> > here.
>
> I'm suggesting the form of a generic wrapper to be used within cfengine
> itself in the form of abstracted package commands.
That would get you a yes or no answer on whether or not *any* version of
the package was installed.
What packages: can do, as it exists in cfengine today, is check for a
package at a specified version. That requires parsing of each commands
specific output to determine the version, plus do version comparison
based on the logic used by that particular package manager.
No matter how much it is abstracted once you sit down to write a
cfengine config file, somewhere deep in the bowels of cfengine,
something has to understand the output of these various commands, in
order to detect and deal with differences in version information.
> > Let me try to illustrate my point with some cfengine code, assuming we
> > used generic names:
> >
> > control:
> > actionsequence = ( packages )
> > PkgInstallCmd = ( /usr/bin/yum )
> > # Note there is no DefaultPkgMgr selected here...
> >
> > packages:
> > SUNWman pkgmgr=sun action=install
> > lsof pkgmgr=rpm action=install
>
> This to me seems like a good idea... Note that the commands are
> generic, but the pkgmgr is used to differentiate.
>
> > So here, I have an environment where I work with Sun's native
> > packages using Sun's native methods, but when I roll my own packages,
> > I use RPM, and when I query for one of those packages, I ask rpm to
> > find it for me. I am not personally doing this, but I've heard of
> > people who do. I have queried Sun's native package manager for
> > SUNWman, and I have queried the rpm database for lsof. I only have
> > one generic install command, but I have told cfengine to install both
> > of these packages.
>
> Firstly, that makes no sense. In fact, if RPM is properly loaded it
> MUST be made aware of installed system programs, in order to resolve
> dependencies correctly.
Even if it does, you still need a different command to install a RPM vs
a native Solaris package. You can custom build all the RPMs you want
for your Solaris machine, but all of the native Sun packages like the
kernel, core utilities, whatever, will not be RPMs. No matter what you
do, you are using one command to install native sun packages, and
another command to install RPMs, whatever that command may be.
I'm not sayin' it's optimal, but the fact of the matter is that
rpm/yum/friends can't/won't install native solaris packages, and pkgadd
doesn't give a flying rat's you-know-what about RPMs.
Extend this to any OS where one may use RPM to manage custom packages,
and the native OS packaging method for OS vendor-supplied packages.
>
> However.... putting that aside.... There is no reason that your
> scriptlet above could not be done using abstraction contained within
> cfengine. Something like:
>
> control:
> rpm.PkgInstall = ...
> rpm.PkgRemove = ...
> sun.PkgInstall = ...
> sun.PkgRemove = ...
How is that different from the variables which with you originally took
issue? The way I see it, that is the same thing as I originally
proposed, sans the .'s of course.
>
> > I'm all for making this more generic if people don't want this
> > flexibility, because I agree that it could pose a scalability issue
> > later.
>
> Who says flexibility needs to be given up?
>
> > If we get rid of pkgmgr= for each item, and just make folks set
> > a DefaultPkgMgr up front, we can make the install command generic.
>
> The example you gave _was_ generic....
It was generic for a reason: I was trying to illustrate that it won't
work. That example used yum to install the packages, yet I had one
check for a RPM package and one check for a native Sun package. You
can't use yum to install a native Sun package (AFAICT from the website -
someone correct me if I'm wrong). So, specifying one install command
and querying for the two different types of packages won't work.
>
> > Of course if we went to a wrapper as proposed, even DefaultPkgMgr
> > becomes useless.
>
> Not necessarily - at least not the way I was thinking of it.
> DefaultPkgMgr would provide a default for your pkgmgr= item. No pkgmgr=
> then use DefaultPkgMgr; otherwise use pkgmgr= to override.
DefaultPkgMgr does that already. My point is that if we go to an
environment where we only allow one install command, then we can only
install one type of package on a given run of the agent. If that is
abstracted into a wrapper program/library external to cfengine as has
been proposed elsewhere in this thread, then cfengine looses control
over what to query to that external facility, and any options inside
cfengine to specify it are useless at that point.
Based on this comment, I get the impression you have not ever used
packages:, even as it exists in current cfengine releases to see what it
does or why. Please, if you have not already, read the docs on
packages: included in the texinfo documentation of cfengine, and try to
use it. As I can tell you, and as the other two gentlemen who have
contributed package manager support to the existing functionality can
probably tell you, the code to support the managers at that level is not
generic.
The argument for abstraction is a good one, and don't think I'm arguing
against trying to get there, but I fear that the issue as it pertains to
the underlying cfengine code required to obtain it is being belittled.
Thanks,
--
Phil D'Amore "Sometimes there is a fine line
Senior System Administrator between criminally abusive
Red Hat, Inc behavior and fun."
Office: 919.754.3700 x44395 -- Ted the Generic Guy
Pager: 877.383.8795 (Dilbert 4/19/2003)
_______________________________________________
Help-cfengine mailing list
Help-cfengine@gnu.org
http://lists.gnu.org/mailman/listinfo/help-cfengine
