[Top][All Lists]

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

Re: Problems configuring cfengine 2.1.17 on Solaris10

From: Dave Love
Subject: Re: Problems configuring cfengine 2.1.17 on Solaris10
Date: Mon, 02 Jan 2006 22:44:33 +0000
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/21.4 (gnu/linux)

[Attempting to post onto Cc:d lists that bounced my reply.]

Mark Burgess <address@hidden> writes:

>> The real pain is the that cfengine requires a non-system version of db
>> (and libcrypto?) which need to be linked statically because `cfexecd
>> -L' isn't useful, since cfexecd links them itself.  You either risk
>> distributing binaries which won't load and break the client, or you're
>> statically linked against an openssl library that may get a security
>> alert.
> I have no idea what this means.

That's worrying.

> Cfengine certainly does not require a "non-system" version of db or
> lib crypto.

That's the first thing INSTALL says, though obviously it's wrong that
you must install the latest versions.  It is an experimental fact that
the current Cfengine will not configure against the Berkeley db and
OpenSSL in /usr on a Solaris 10 system which was fully updated within
the last fortnight, any more than it will on other versions of
Solaris, Irix &c.  [It _may_ be that cfengine _could_ use them on
Solaris 10 with autoconf changes but obviously there's no point in

> They do not need to be statically linked.

No, as I said above, but experience of actually maintaining a network
of Solaris (amongst other) boxes shows that if you don't statically
link them, you probably end up with broken installations when the
clients miss the dynamic libraries for one reason or another.  Some
admins may be perfect and won't have such trouble, and mileage always

> What kind of nonsense is this?
> Apologies for this misinformation. 
> Cfexecd -L has nothing to do with static linking, it is for working
> around broken ldso.conf

ld.config on Solaris, perhaps, but that's not broken on my systems,
and if I wanted to create one, I have an equivalent maintenance issue.
Even if the doc is wrong about -L (though it agrees with the code), it
simply isn't likely to be useful; if it's necessary then cfexecd
probably won't load as ldd shows.  For what it's worth, if I remember
correctly that's a regression which I may even have failed to report
via the useless bug address.

I've come to the conclusion that cfengine maintenance makes it
something one doesn't really want to rely on in the sort of situation
I've been in where it's actually supposed to win.  This sort of
response confirms that, unfortunately.

reply via email to

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