( Lloyd, Now _I'm_ the one slow to respond ! )
> * What do you see as the benefit of the PATH variable in the manifest > over hard-coding the absolute path to cfengine binaries? I use the PATH variable, to allow for the special case of the very-first run of CFEngine My CFEngine package installs into /usr/local/sbin ... and does not touch /var/cfengine/bin (I also have a "cfclient" package, that has the initial /var/cfengine/inputs and /var/cfengine/ppkeys/ ... and I don't put binaries in there either) Anyway, the package installs, and SMF kicks off the daemons ... from /usr/local/sbin cfagent runs (from /usr/local/sbin), reads update.conf & cfagent.conf, and copies the CFEngine binaries to /var/cfengine/bin. ... then sets a class which causes the daemons to restart. ... this time from /var/cfengine/bin. I don't have the package put binaries in /var/cfengine so that when I update the package, CFEngine is running with known-good executables. Also (in update.conf)---before copying the daemons from /usr/local/sbin to /var/cfengine/bin---I have cfagent test to see if (/usr/local/sbin/cfagent -z) bombs out. This is there to catch any library-linking errors introduced by a newly installed cfengine build/package. If there's an error, then no copy is done: /var/cfengine/bin is still good. ... If my cfengine package pushed the new binaries to /var/cfengine/bin, then the cfengine install would be trashed. And since cfengine is how I push-out new cfengine packages .... the music stops. ;-) And I can't handle both those cases if I hard-code paths in the manifest (rc files, etc) --David -----Original Message----- From: Justin Lloyd [mailto:jll...@digitalglobe.com] Sent: Friday, April 23, 2010 1:53 PM To: Welborn, David; help-cfengine@cfengine.org Subject: RE: Solaris 10 Cfengine SMF service So after tweaking my manifest file a bit more and playing with in on a test system, I could be wrong but I think that Cfengine, as it is written, won't work well as an SMF service. As soon as cf-execd is started by enabling the service, it's getting killed and restarting over and over. I think this may be due to how it checks for updates, killing itself so it can restart with new config files, or something to that effect. Here's part of /var/svc/log/cfengine, which is started when I run either "svccfg import cfengine.xml" or "svcadm enable cfengine" if it's already imported: [ Apr 23 18:15:42 Method "start" exited with status 0 ] [ Apr 23 18:15:42 Stopping because process received fatal signal from outside the service. ] [ Apr 23 18:15:42 Executing stop method ("/lib/svc/method/cfengine stop") ] Stopping Cfengine Nova [ Apr 23 18:15:43 Method "stop" exited with status 0 ] [ Apr 23 18:15:44 Executing start method ("/lib/svc/method/cfengine start") ] Starting Cfengine Nova [ Apr 23 18:15:46 Method "start" exited with status 0 ] [ Apr 23 18:15:46 Stopping because all processes in service exited. ] [ Apr 23 18:15:46 Executing stop method ("/lib/svc/method/cfengine stop") ] Stopping Cfengine Nova [ Apr 23 18:15:47 Method "stop" exited with status 0 ] [ Apr 23 18:15:47 Executing start method ("/lib/svc/method/cfengine start") ] Starting Cfengine Nova etc. I think I'm going to go back to just an /etc/init.d/cfengine script on Solaris. I have an RFE open with Cfengine for an official service, but if my assumption proves to be correct, it may be more complicated than I thought. However, if anyone thinks I'm wrong and knows how to fix this, I'm open to suggestions. :) Justin -----Original Message----- From: help-cfengine-boun...@cfengine.org [mailto:help-cfengine-boun...@cfengine.org] On Behalf Of Justin Lloyd Sent: Wednesday, April 21, 2010 11:26 AM To: Welborn, David; help-cfengine@cfengine.org Subject: RE: Solaris 10 Cfengine SMF service David, Sorry I've taken so long to respond to this. * I'll use my new test environment to move the actions into the xml file as you've done. Eliminating the method script is certainly appealing since zones slightly complicate matters, requiring a manifest file per zone but all zones sharing a single method script. * I'll personally stick with a single FMRI, site/cfengine:default, since I only need the service to manage a single daemon, cf-execd as the policy manages cf-serverd and cf-monitord. * Right now, I *am* the Cfengine team. :P However, I am working on documentation to eventually transition it to the Unix team, to which I'm still an adjunct (and was directly part of ever since I started at this job). * What do you see as the benefit of the PATH variable in the manifest over hard-coding the absolute path to cfengine binaries? Thanks for the feedback! Justin ****************************************************************************************** This message may contain confidential or proprietary information intended only for the use of the addressee(s) named above or may contain information that is legally privileged. If you are not the intended addressee, or the person responsible for delivering it to the intended addressee, you are hereby notified that reading, disseminating, distributing or copying this message is strictly prohibited. If you have received this message by mistake, please immediately notify us by replying to the message and delete the original message and any copies immediately thereafter. Thank you. ****************************************************************************************** CLLD _______________________________________________ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
