Tags: 3.5.0

07/04/13

  02:58:00 pm, by The Dreamer   , 254 words  
Categories: Software, FreeBSD, CFEngine

hindsight on cfengine 3

In retrospect, maybe what I should've done is switched the origin of my sysutil/cfengine to sysutil/cfengine34 when 3.5.0 came out. Since, I see that cfengine-3.4.5 has recently come out, bug fixes to cfengine-3.4.4 were more of what I was after than new features. Though I am intrigued by what 3.5.0 appears to bring, and am considering making use of it...of course, by the time I get to it 3.5.1 or newer might be out.

OTOH, do I really want to build cfengine-3.4.5 in semi-usable package management system we use at work for building and maintaining packages for Solaris 9 and Solaris 10 SPARC, and Solaris 10 x64. The system builds everything 32-bit, though I'm pretty sure we don't have 32-bit hardware anywhere in the datacenter anymore. Though we still have a few Solaris 10 systems around.

Hmmm....

% wget 'https://www.cfengine.com/source-code/download?file=cfengine-3.4.5.tar.gz'
--2013-07-04 08:39:34--  https://www.cfengine.com/source-code/download?file=cfengine-3.4.5.tar.gz
Resolving www.cfengine.com (www.cfengine.com)... 62.109.39.150
Connecting to www.cfengine.com (www.cfengine.com)|62.109.39.150|:443... connected.
OpenSSL: error:14077458:SSL routines:SSL23_GET_SERVER_HELLO:reason(1112)
Unable to establish SSL connection.

:hmm:

Seems to be a problem with a client using openssl 0.9.8 talking to a webserver using 1.0.0?

Guess there's a patch submitted against 0.9.8y.... http://www.mail-archive.com/openssl-dev@openssl.org/msg32486.html

But, this will be a big mess at work....nothing is using 0.9.8y yet (though I've been meaning to build it so I'll be ready when there's a bind-9.9.3-P2...had started building 9.9.3 when there was a security advisory of problem introduced in that version...so I'm waiting for the next 'real' security patch to do the upgrade...though maybe I shouldn't, since the intent is for this to be the first 64-bit build....)

Not sure what I'm going to do about cfengine3 at work though....

06/15/13

  04:04:00 pm, by The Dreamer   , 1123 words  
Categories: Software, FreeBSD, CFEngine

cbox/dbox cfengine update also full of fail

First I had saved libpromises.so.1, so that I could invoke cf-agent from /var/cfengine/bin to pull in the new cfengine-3.5.0 binaries and pull up the new inputs from my policy server.

Except I forgot to commit the 'bundle agent foo' kluge, and I had done an 'svn revert ...' to undo all the fiddling I had been doing on the policy server.

But, after I make the change, cbox/dbox refuse to copy up the new 'do-crontab.cf' file. I try running things verbose, 'cf-agent -v > out', but there's no out file??? :??: Did I slip? Am I losing my mind?

Guess I should do it in another directory, because the update does purge...so its removing my 'out' file. :oops:

So, its saying this:

2013-06-15T14:40:55-0500  verbose: Entering directory '/var/cfengine/inputs'
2013-06-15T14:40:55-0500  verbose: Device change from 1242801830 to 843968349
2013-06-15T14:40:55-0500  verbose: Skipping '/var/cfengine/inputs/do-mysql.cf' on different device
2013-06-15T14:40:55-0500  verbose: Device change from 1242801830 to 843968349
2013-06-15T14:40:55-0500  verbose: Skipping '/var/cfengine/inputs/do-ddclient.cf' on different device

What are those device numbers....is it saying that because the file is remote that it won't copy it? After some looking around....I see that 'u_recurse("inf")' is:

body depth_search u_recurse(d) {
        depth   => "$(d)";
        xdev    => "true";
}

Which seems perfectly reasonable that I want it to recurse the destination directory and not cross devices. But apparently, it now means don't recurse into devices that different than the source directory's device???

I look around to see if I had done the 'xdev' line or if that was from where I based my initial setup from....and find that its what was giving over on Unix Heaven - http://www.unix-heaven.org/node/53#cf3-update

That change in behavior totally doesn't make any sense? But, enough hair pulling.... let's get things running again on cbox & dbox.

Hmmm, now its spewing warning messages:

2013-06-15T14:47:31-0500  warning: Setting replace-occurrences policy to 'first' is not convergent
2013-06-15T14:47:32-0500  warning: Setting replace-occurrences policy to 'first' is not convergent
2013-06-15T14:47:32-0500  warning: Setting replace-occurrences policy to 'first' is not convergent
2013-06-15T14:47:33-0500  warning: Setting replace-occurrences policy to 'first' is not convergent
2013-06-15T14:47:33-0500  warning: Setting replace-occurrences policy to 'first' is not convergent
2013-06-15T14:47:35-0500  warning: Setting replace-occurrences policy to 'first' is not convergent

I didn't before...and there's only one occurrence, so it is convergent. And, my use of 'replace_with => With("...")' for 'replace_patterns:' was lifted from -- https://cfengine.com/archive/manuals/cf3-solutions. So, in With(), I should change 'occurrences' from "first" to "all"....why have this attribute if its purpose is just to annoy now?

Its already annoying enough that -q is gone....but -K remains? If I'm running a cf-agent manual to speed up picking up a change....I'd like having to wait splaytime, but I don't want to ignore locks...because if I'm close to when cf-execd wants to run....it results in a big mess, especially for promises using single copy nirvana.... cf-agent doesn't distinguish on why the specific copy failed when there's a collision in this case, so it causes a less specific version to get copied....so that it has to fix it in the next run.

This causes problems for things like DNS and NTP. The specific is cbox is an NTP server that polls external servers in the freebsd.pool.ntp.org....and the generic NTP config is to use cbox and dbox as NTP servers....which has resulted in wild client oscillations, though both my dsl and cable connections have been rather unstable lately...though dsl will just have periodic drops, cable goes out until I reboot my cable modem....and the fact that using two NTP servers is probably the worst combination. But, I don't think I could get away with 4+ NTP servers on my home network. DNS....well, specific is cbox is primary authoritative, dbox is secondary authoritative, and generic is recursive caching resolver....similar to how I did DNS servers under cfengine at work.....

4+ justification - http://www.ntp.org/ntpfaq/NTP-s-algo-real.htm#Q-NTP-ALGO

NTP likes to estimate the errors of all clocks. Therefore all NTP servers return the time together with an estimate of the current error. When using multiple time servers, NTP also wants these servers to agree on some time, meaning there must be one error interval where the correct time must be.

Number of servers:

  1. Always trusted, even when its totally wrong
  2. If they differ, how do you break the tie?
  3. A server failing results in above.

So, 4+ servers for reliable accuracy.

Whether the total should be odd or some other sequence, is another debate.

http://www.ntp.org/ntpfaq/NTP-s-config-adv.htm#Q-SERVER-NUMBER

But three is a good place to start, and you can progress to three-groups-of-three if you feel the need.

three-groups-of-four? four-groups-of-four?

Hmmm, I don't know why I had never done 'cf-agent -v > out' in /var/cfengine/inputs on cbox/dbox before....but often do it on my policy host. I guess I don't normally need to be in /var/cfengine/inputs on cbox/dbox when I'm troubleshooting cfengine.

Hmmm, so the verbose run, I only see two places with warnings??? That seems odd.

cf3>     .........................................................
cf3>     Promise's handle:
cf3>     Promise made by: "name="tor""
cf3>     .........................................................
cf3>
cf3>  -> Looking at pattern name="tor"
cf3> WARNING! Setting replace-occurrences policy to "first" is not convergent
cf3>  -> Verifying replacement of "name="tor"" with "name="tor2"" (2)
cf3>  -> Replace first occurrence only (warning, this is not a convergent policy)
cf3>  -> Replaced pattern "name="tor"" in /usr/local/etc/rc.d/tor2
cf3>  -> << (2)"name="tor2""
cf3>  -> >> (2)"name="tor2""
cf3>  -> Replace first occurrence only (warning, this is not a convergent policy)

Wait....it makes even less sense.... this edit promise is about creating /usr/local/etc/rc.d/tor2 from /usr/local/etc/rc.d/tor. Since the starting file is fixed, the first occurrence is inherently fixed...so replacing it is convergent. So, its just there to annoy.

And, wait....its also having issues using recurse() from cfengine_stdlib.cf....well, it has xdev => "true"; set as well. And, that body is unchanged from the previous version.

Oh, I suppose I could remove splaytime.... its not like that I have a huge number of systems....

Wait... the tor2 edit_lines also has an if_elapsed("60"), so warnings are from other edits that were probably skipped. Guess, I'll have to risk a -K to find all the occurrences of the warning.

Though its strange that I'm only seeing the messages on dbox, even though the promise exists for both cbox & dbox....

OTOH, on cbox it did catch an error.... where it was promise that "/usr/local/www/apache22/data/tivo/.", etc. was accessible to the webserver Except I had typed "/usr/local/www/apache2/data/tivo/.", etc. There was no error/warning about skipping this promise before. Though in 3.5.0, it gave an error that it couldn't chdir to this directory...which delayed me into noticing the actual reason for the error.

And, once again...another wasted Saturday.... I didn't really need to go to the mall and spend money I don't have, I suppose. &#58;&#104;&#109;&#109;&#58;

Now before I can go back to just doing 'portmaster -a' to keep current....I still need to decide the fate for the databases/mysql55-server update.... I suppose while cfengine was down, I could've done the upgrade if the decisions was to stay put. But, still wondering if I want to try percona, or perhaps better yet, maria! I wonder what my friend Maria is up to these days....

  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

failsafe.cf

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....

Full story »

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

bloglovin

There are 20 years 9 months 21 days 44 minutes and 34 seconds until the end of time.
And, it has been 4 years 3 months 7 days 13 hours 18 minutes and 22 seconds since The Doctor saved us all from the end of the World!

Search

March 2017
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 31    
Google

Linkblog

  XML Feeds

Who's Online?

  • Guest Users: 3
This seal is issued to lawrencechen.net by StopTheHacker Inc.
blogging tool

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

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