« cbox/dbox cfengine update also full of failPerl update continued »

Meanwhile upgrading cfengine-3.4.4 to cfengine-3.5.0 not going well.


  01:15:00 pm, by The Dreamer   , 694 words  
Categories: Software, FreeBSD, CFEngine

Meanwhile upgrading cfengine-3.4.4 to cfengine-3.5.0 not going well.

Upgrading the port was no problem....but it broke my cfengine. Why? The port puts the cfengine binaries in /usr/local/sbin, while the cfengine practice is that it has a private copy in /var/cfengine/bin. Which would be fine if the binaries didn't have shared library dependencies. Which they do, specifically libpromises.so.1 which is gone in cfengine-3.5.0...there's a libpromises.so.3.

Though before I discovered this problem, I first wanted to make some tweaks to update.cf so that I would have some indication that it had copied up new binaries from /usr/local/sbin to /var/cfengine/bin, since I noticed that files there newer than expected. Though I probably just rebuilt the same version port because a dependency had updated and /usr/ports/UPDATING indicated that I need to do that.

This probably is why at work, the person that setup our cfengine 2 went to extreme effort to create static cfengine executables...ignoring that such things are officially not supported on Solaris. Though we seemed to get away with running those executables, built on a Sol10u3 sun4u system...on systems more current up to Sol10u11, and a few Sol11 systems and systems that are sun4v architecture.

In a past life...we had run into a statically built executable (the installer) not working on our first UltraSPARC-III system (Sun v280r)...trying to recall what our build machine was back then.... my recollection says we only had the SPARCserver 20 and SPARCstation 10, before that. Though as I recall, we had to wait for a patch from Sun as well as rebuild the executable shared on the SPARCserver 20...to have it work. It wasn't long after that though that we retired support for sun4m, changing minimum requirements. Wonder if the application has become 64-bit yet? But, for ABI backwards compatibility claim to work, the executable needs to be built shared...so that it'll find the libraries provided on newer systems to allow older executables to still work.....

portmaster probably didn't know that it should save /usr/local/libexec/cfengine/libpromises.so.1, though would the old executables know how to find the library when its moved aside? (I do have SAVE_SHARED=wopt uncommented in my portmaster.rc file).

Occurs to me that I could just restore the file from backup, it would allow me to run


and get me to where everything should work again.

Though before I did that, I had invoked cf-promises (the one in my path -- /usr/local/sbin), and it complains about library.cf. Guess it doesn't like the old cfengine_stdlib.cf, the new one isn't where the old one was....it was here instead --> /usr/local/share/cfengine/CoreBase/libraries/cfengine_stdlib.cf I do a quick look at what's in it....mainly to make sure that bundles/bodies that I use are still there...and notice some interesting new ones....such as a package_method of freebsd_portmaster, someday I should look at cfengine3 to do port/package promising....

But first get cfengine working on policyhost, hopefully the other servers (at 3.4.4) are still working.....guess not, 3.4.4 doesn't like the 3.5.0 cfengine_stdlib.cf file. But, cf-promises is also not happy with some of my other promises....

Guess I'll update those while I get policyhost working again.


Or perhaps I need to revert....

root@zen:/var/cfengine/inputs 317# cf-agent
2013-06-15T13:22:53-0500    error: Bundle 'crontab' listed in the bundlesequence is not a defined bundle
2013-06-15T13:22:53-0500    error: Fatal CFEngine error: Errors in promise bundles
1.755u 0.113s 0:01.94 95.8%     172+2501k 133+12io 1pf+0w
root@zen:/var/cfengine/inputs 318# 
# cf-agent -v
2013-06-15T14:00:57-0500  verbose: Parsing file '/var/cfengine/inputs/do-crontab.cf'

Its there, why's it not working.... 'cf-agent -d' doesn't work, but it will only do failsafe....

...so I cheat by copying promises.cf over failsafe.cf, but I can't make heads or tails of what's going on, except that its parsing it

2013-06-15T14:05:12-0500  verbose: Parsing file '/var/cfengine/inputs/do-crontab.cf'
L:line # do-crontab.cf
L:line bundle agent crontab {
        L:bundle 6
        L:id agent 12
        L:id crontab 20
        L: { 22
P:bundle:agent:crontab begin body open
L:line files:
        L:promise_type files: 6
        P:bundle:agent:crontab promise_type = files
L:line  "$(g.crontab)"
        L:qstring "$(g.crontab)" 15
        P:bundle:agent:crontab:files:any promiser = $(g.crontab)
L:line          comment         => "Add lines to /etc/crontab",
        L:id comment 9
        P:bundle:agent:crontab:files:any:$(g.crontab) attribute = comment
        L:assign 13
        L:qstring "Add lines to /etc/crontab" 41
        P:bundle:agent:crontab:any qstring rval, comment = Add lines to /etc/crontab
L:line          edit_line       => add_crontab_lines;
        L:id edit_line 11
        P:bundle:agent:crontab:files:any:$(g.crontab) attribute = edit_line
        L:assign 15
        L:id add_crontab_lines 33
        P:bundle:agent:crontab:any id rval, edit_line = add_crontab_lines
L:line }
        L: } 1

Eventually for grins....I put this block in front of my 'bundle agent crontab'

bundle agent foo {

And, that seems to make it all work again.

Now to see about the other boxes.

No feedback yet

Now instead of subjecting some poor random forum to a long rambling thought, I will try to consolidate those things into this blog where they can be more easily ignored profess to be collected thoughts from my mind.

Latest Poopli Updaters -- http://lkc.me/poop


There are 17 years 3 months 25 days 16 hours 53 minutes and 4 seconds until the end of time.
And, it has been 7 years 9 months 1 day 21 hours 9 minutes and 52 seconds since The Doctor saved us all from the end of the World!


September 2020
Mon Tue Wed Thu Fri Sat Sun
 << <   > >>
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30        


  XML Feeds

Who's Online?

  • Guest Users: 2
This seal is issued to lawrencechen.net by StopTheHacker Inc.

hosted by
Green Web Hosting! This site hosted by DreamHost.

monitored by
Monitored by eXternalTest
SiteUptime Web Site Monitoring Service
website uptime