Tags: cfengine3

Pages: 1

08/04/13

  06:03:00 pm, by The Dreamer   , 976 words  
Categories: FreeBSD, CFEngine

Wonder if this will work - package_method=>freebsd_portmaster and /var/db/pkg

On my FreeBSD system, my apache webserver would get angry whenever I update the php & extensions ports. Requiring a bunch of other operations after the 'portmaster -a'.

Since I've been playing around with CFEngine 3, I had started to add to my "bundle agent apache", to do more than just promise config files current, process running, reloads, etc.

So, one of the first problems I had run into on FreeBSD, is that there are certain extensions that need to be in order in '/usr/local/etc/php/extension.ini'. Which is solved by using fixphpextorder.sh.

Well, fortunately when this script is run it results in a backup file of 'extensions.ini.old' which is the same age or newer than 'extennsions.ini'.

CFEngine3 can take care of it this way:

Code

vars:
 
    "ext_dir"       string => "/usr/local/etc/php";
 
    "ext_file"      string => "extensions.ini";
 
    "fix_php_ext"   string => "/usr/local/etc/fixphpextorder.sh";
 
classes:
 
    "need_fix_php" expression => isnewerthan("$(ext_dir)/$(ext_file)","$(ext_dir)/$(ext_file).old");
 
commands:
 
    need_fix_php::
 
        "$(fix_php_ext)"    contain => in_dir("$(ext_dir)");
 
        "$(g.lrc_d)/$(g.apache) graceful";

g.apache is "apache22" currently on FreeBSD, and "apache2" on Ubuntu. Someday it might become "apache24" on FreeBSD.

Since I did FreeBSD first, and I'm still working on getting my one of 4 (or less) Ubuntu rolled in, I have:

g.rc_d as "/etc/rc.d" and g.lrc_d as "/usr/local/etc/rc.d" for FreeBSD. They are both set to "/etc/init.d" for Ubuntu. I also have a g.init_d for Ubuntu, but not FreeBSD. Not sure which I'll use where....I suppose if its an OS specific case, g.init_d would get used and if its not...then which ever one is the correct one for FreeBSD will get used.

Pages: 1· 2

07/28/13

  01:14:00 pm, by The Dreamer   , 3144 words  
Categories: Software, Operating Systems, Ubuntu, FreeBSD, CFEngine

Last two weekends - nagios and more cfengine 2 & 3

So, what started as take a week to set up a new nagios server at work ended up taking almost a month...because there were many days where I'd only have an hour or less to put some time into the side task. The other stumbling block was I had decided that the new nagios server configuration files would get managed under subversion, instead of RCS as it had been done in the previous two incarnations. New SA's don't seem to understand RCS and that the file is read-only for a reason...and its not to make them use :w! ... which lately has resulted in a the sudden reappearance of monitors of systems that had been shutdown long ago.

Though now that I think of it, there used to be the documented procedure for editing zone files (back when it was done directly on the master nameserver and version controlled by RCS.) Which as I recall was to perform an rcsdiff, and then use the appropriate workflow to edit the zone file.

% rcsdiff zonefile

if differences

      % rcs -l zonefile
      % ci -l zonefile
        make rude comment that somebody made edits
      % vi zonefile
      % ci -u zonefile

else

      % co -l zonefile
      % vi zonefile
      % ci -u zonefile

fi

But, when I took over managing DNS servers, I switched to having cfengine manage them and the zone files now live under masterfiles, so version control is now done using subversion. Had started butchering the DNS section in the wiki, probably should see about writing something up on all the not so simple things I've done to DNS since taking it over...like split, stealth, sed processing of master zone for different views, DNSSEC, the incomplete work to allow outside secondary to take over as master should we ever get a DR site, and other gotchas, like consistent naming of slave zone files now that they are binary.

Additionally work on the nagios at work was hampered by the fact that for Solaris and legacy provisioning is CF2, and the new chef based provisioning is still a work in progress...where I haven't had time to get into any of it yet. So, I had to recreate my CF3 promises for nagios in CF2.

But Friday before last weekend it finally reached the point where it was ready to go live. Though I've been rolling in other wishlist items and smashing bugs in its configuration, and still need to decide what the actual procedure will be for delegating sections of nagios to other groups.

One of the things I had done with new nagios at work, was set up PNP4Nagios...as I had done at home. And, while looking to see if I needed to apply performance tweaks to the work nagios, all the pointers were to have mrtg or cacti collect and plot data from nagiostats. Well, a new work cacti is probably not going to happen anytime soon, and the old cacti(s) are struggling to monitor what they have now (I spent some time a while back trying to tune one them...but its probably partly being hampered by the fact that its mysql can use double the memory that is allocated to the VM. though reducing it from running 2 spine's of 200 threads each...on the 2 CPU VM to a single spine with fewer threads has helped. Something like the boost plugin would probably help in this case, but the version of cacti is pre-PIA. But, it could be a long time before it get's replaced (not sure if upgrade is possible....) Our old cacti is running on a Dell poweredge server that has been out of service over 6 years... with the cacti instance over 8 years old (Jul 8, 2005)....and the OS is RHEL3.

Anyways, it occurs to me that there should be a way to get PNP4Nagios to generate the graphs, and I search around and find check_nagiostats. Though no template for it. Oh, there's a template nagiostats.php, if I create a link for check_nagiostats.php it should get me 'better' graphs. Which is what I have CF2 do at work.

Full story »

Pages: 1· 2· 3

07/14/13

  05:58:00 pm, by The Dreamer   , 2452 words  
Categories: Software, Ubuntu, FreeBSD, CFEngine

Moving irssi

So, recently there was a 'long' 4th of July weekend....on account that I opted to take Friday (the 5th) off as well.

I kind of thought I would tackle a bunch of different projects this weekend, though I've pretty much shelved the idea of re-IP'ng my home network. Perhaps something to do when I get my configuration management better fleshed out.

What I decided was that it looks like its just one last thing on one of the two Ubuntu servers that I'm retiring. So, I figured I'd quickly move that and then go onto the next thing. In the end, I didn't get it completed until Monday night.

For background, some years back...after my return to IRC, I had initially gone with Chatzilla (being that Firefox was my standard browser), which later moved to xulrunner and Chatzilla so it was independent of my browser. Though it was kind of annoying having it running at work and at home, and somewhat confusing for co-workers that ran text based IRC clients in screen somewhere and ssh'd in, etc. Most people that did this, were doing irssi.

So, I initially built it from source and was running on my old RedHat 7.3 server, and that was usable. Later when I setup an Ubuntu box to replace that server (the hardware had previously been SuSE....acting as an internal router for ivs status tracking....) It evolved, in that I would start screen detached from rc.local....which was important since the system would see patches on a regular basis, requiring reboots....which is kind of a reason for switching to FreeBSD.

Over time, I would make little tweaks here and there, to this irssi setup. Like twirssi, doing ssl, and later bitlbee to integrate Facebook chat (came across some stuff that I should add now...)

And, incorporating other tweaks I come across online when there's some problem that becomes sufficient bothersome that I want to address. The one problem I haven't haven't been able to solve is keeping server/system messages confined to the one window. Namely keeping system CRAP going to the system window, and allow channel CRAP to show up in the channel windows....but instead I'll get system CRAP in whatever channel window is active. Which is annoying because its usually the work channel. Where it be just signal and no noise.

Anyways...

I had started to move things more than a month ago, in that I built irssi and bitlbee (including the cfengine3 promise for it...not really much config wise for cfengine to manage for irssi...though I envisioned promising that its running all the time, though irssi has generally been stable everywhere else that I've run it.

But, the I got distracted by other cfengine3 work. Even though things started to get pressing when twirssi stopped working, due to API 1.0 going away...so I had to update Net::Twitter and twirssi. Updating twirssi wasn't that hard to do, but Net::Twitter was a problem, so I opted to remove it and its dependencies and then installing it and its dependencies using CPAN.

I also made note to install net/p5-Net-Twitter from ports on dbox.

twirssi seems to be having other issues, which I had intended to investigate...perhaps after I move... But, that was like a month ago....

Full story »

Pages: 1· 2

07/04/13

  05:59:00 pm, by The Dreamer   , 476 words  
Categories: Software, CFEngine

Upgrading from CFEngine 2 to CFEngine 3

I just learned of a key missing detail that would probably have helped lots of other CFEngine 2 sites make the transition to becoming CFEngine 3 sites.

All the sites, include CFEngine's have docs about Upgrading from CFEngine 2 to 3....

Where, the touch, or go in-depth, on conversion of policies from 2 to 3, extol how 3 is better than 2, and then offer vague options on how to upgrade (either in-place or replace)....

The most detailed explanation was a slide deck...which wasn't detailed enough.... that says "CF2 and CF3 designed to be interoperable", "Replace CF2 policies at your pace". How?

In-Place Upgrade

"Replace cfexecd with CFEngine 3's cf-execd" - Access controls remains untouched, runs cf-agent.

"Sample input files contain integration promises" - Launched automatically, Changes crontab

And, then get's in the steps:

  • Install CFEngine 3
  • Copy new inputs files to CF2 master repository
  • Remove any rules to reinstall CF2 or add cfexecd or cfagent to crontabs
  • Remove cfexecd from start up
  • Edit update.cf
  • set email options for executor in promises.cf
  • cf-agent --bootstrap

If all went well, you are now running CFEngine 3.

Bootstrap policy server using:

cf-agent --bootstrap --policy-server

  • Remove all rules and policies that are capable of activating CFEngine 2 components
  • Convert cfservd.conf into a server bundle
  • Place a reference to this in promises.cf
  • Add converted CFEngine 2 policies or create new CFEngine 3 policies
  • Done???? :??:

    Somethings missing....where's this interoperability taking place? Does CF3 know how to run CF2 policies? no... where's this replace CF2 with CF3 at my pace? Reads like its a full in-pace replacement of CF2 to CF3....

    So I finally made a reference about this on a list...

    Answer?!

    It's why the CF3 binaries have dashes in the name. So you can drop them into the CF2 working directory.... The trick is editing the exec_command in the executor configuration, that's the command for running the agent; modify it to run both agents (v2 and v3).

    Wow...that's kind of an important detail that's been missing!

    Full story »

      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/24/13

      08:57:00 am, by The Dreamer   , 838 words  
    Categories: Home Theatre, Software, Momitsu V880N, FreeBSD, CFEngine

    This just in, cfengine developers don't test or use cfengine!?

    So, this morning I was was wonder why my nagios was still warning about something that it shouldn't be. I was positive I had changed the warning threshold above where it was. I do an 'svn status' on my work dir, nothing uncommitted. I do an 'svn up' on the cfengine server....no updates, I drill down to the file and its correct (perhaps I need an alias on this side as well...though I usually only use 'cdn' for where my svn work dir is or on the nagios server....though its because at work....where this alias is used in association with nagios as well (where work nagios is not yet managed by cfengine, but was considering it for the new nagios server that I'm trying to set up between fires and stuff at work....except the fact that we're still running cfengine2 is really starting to become a problem......though I wonder if cfengine2 could do it, if it weren't hampered by how former admin had implemented things....The work cfengine made a mess with using it to setup a new system because of weird cross interactions between 'promises' and that the promise wasn't written in the same sequence it was running, things that probably aren't a problem when cfengine was original deployed to promise that nothing ever changes....)

    Anyways....I finally hunt through the -v output... which is now not much different than debug noise, and nothing like what verbose used to be in 3.4.4.....no more search for 'E nagios' to find where the start of "BUNDLE nagios" is in the out, and then finding the specific file promise..... what a mess. Its like they don't want you to know what's going wrong....

    Turns out I missed some more uses of 'recurse' from cfegine_stdlib.cf, where xdev=true is busted.

    It was one of three bugs that I had logged for cfengine 3....#2983. Which was almost immediately flagged as a duplicate of #2965 (3.5.0rc fails to recursively copy files with strange message)...and this morning at 5:03am, my bug was closed as that it indeed seems to be fixed for 3.5.1 (soon...).

    Wonder what the definition of soon is....had a previous problem where cfengine was complaining about bad regex....when the default for insert_lines: is that they are 'literal' strings. Which was making it hard to use cfengine 3.4.x to make edits to my crontab files. After putting up with it for a couple of months, I finally visit the bug tracker and find that its already been reported and fixed for next version. But, months and months go by and no new version appears. Though it does seem to be fixed in 3.5.0.

    Anyways reading #2965 was interesting.... aside from where the dev? spots another bug in the same code and has that pulled as part of the bug. Also that it was reported against RC, and made it into release. Though I had reported a bug in against an ubuntu 12.04 beta release....and it persisted into the release version, where they debated fixing it because apparently LTS means don't update anything after its release...(though I thought they had said things like firefox would stay current instead of staying fixed at the version at time of release now...) Plus it seemed I had to keep reminding them that my bug was reported before release, so that should be reason enough to release the fix. I'm pretty sure they did, but I hardly use that ubuntu desktop anymore (or any ubuntu desktop....though I did fire up my laptop yesterday, but its because there was a new VirtualBox and I hadn't updated the XP VM on there in quite some time....though I've been thinking of whether a FreeBSD laptop is feasible.)

    Someone asks that they have a unit test for this bug. Where the response is a unit test would need a running server, which they don't have (yet)...how long has cfengine been around for them to not be using it? Sure wouldn't want to be somebody who's paying for this.

    So does that mean nothing is being tested, and that nobody involved in development use cfengine? Because this was the kind of bug that pretty much anybody that uses cfengine3 would run into. Considering I only have the 3 systems (zen - policyserver, cbox, dbox) at the moment....

    Perhaps I'm jaded by having worked for an Enterprise software company and how we did full builds every week, and with full runs of automated and manual QA testing. And, having to create unit tests for less than trivial bugs as part of fix/review before closure process. Though what I'm hearing about Chef...its worse....

    Still haven't decided what I'm going to do with my Linux systems....migrating the files from Orac if I were to turn it into FreeBSD is the stumbling block, plus I would lose certain services...some of which might not really be an issue, since its probably time I make the leap to blu-ray. And, either I get another Roku or figure out how to incorporate the smart side of my TV into my life (probably time to finally upgrade my receiver....purchased October 27th, 1999)....

    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 »

    06/14/13

      08:36:00 am, by The Dreamer   , 959 words  
    Categories: Software, FreeBSD, CFEngine

    Perl update + cfengine3 and subversion == great big mess on FreeBSD

    So being up ridiculously early this morning, because I got up at the right time during the night...but forgot to take my second dose, and too late to take it when I woke again.

    So, I thought I would tackle updating to the latest perl on zen. Choose not to just do a blind 'portmaster -r perl', since that would include anything that depends on being able to run perl or depends on something that depends on perl...possibly many levels down. Somebody should come up with a simple way to only rebuild the ports that directly depend on another port....

    What I decided to do what after updating perl, was 'portmaster p5-*' then do a pkg_libchk to see what ports are missing libperl.so and redo those.

    I did this first by logging into my machine at work (mew) and it went quickly and worked pretty cleanly. Though there are only half the number p5- ports, and less ports missing libperl.so as well.

    So, back on zen...I updated perl and then started the 'portmaster p5-*', when it stopped. A port is dependent on /usr/local/bin/perl5.14.2, which is not found because I just updated to 5.14.4!

    How do you have ports that are dependent on a specific version, especially since its possible to have a different version of perl. When I first installed zen, the default perl was 5.12.x...but I had elected to upgrade to 5.14.x when that became the new default. OTOH, when I setup cbox/dbox, I opted to go with 5.16.x...and at work, mew had started before zen, so it was also 5.12.x initially...but I choose to jump that up to 5.16.x (actually no .x at first, but it was very quickly followed by a .1...which inflicted a lot of pain again....though in this latest update they have switched to just major.minor for module path, which means no more pain until its time to upgrade to a newer minor release....

    The first casualty was devel/p5-B-Keywords ...and I find its depended on by textproc/p5-Perl-Critic and textproc/p5-Test-Perl-Critic....with the last port being the leaf. So that seems to be that it was probably just a build depend for something I had installed long ago (since it doesn't sound like anything I could call in any of my own perl scripts.) So, I figure I'll just delete those packages and carry on.

    Nope, the next port also fails with the same strange demand.

    &#58;&#35;&#35;

    After hunting around a bit, to try and figure out what is making this port think it depends on the previous version of perl...it dawns on me that the perl port updates /etc/make.conf as to what version of perl is installed.

    And, I have

    /etc/make.conf

    being managed by cfengine3. &#58;&#111;&#111;&#112;&#115;&#58;

    So, I go update the file, and try to svn commit the change....which blows up because the perl modules needed for the commit hook haven't been updated yet.

    Well, guess I'll stop cfengine3 from reverting my /etc/make.conf (by disabling the promise from the root side) Though IIRC now, the commit hook is mainly to prevent root from doing commits into my subversion repository, instead of the put subversion on an NFS filesystem and have rootsquash prevent root from being able to write into the repository, that we do at work.

    Phew....I can commit updated /etc/make.conf and let cfengine promise it. Perhaps in a future project, I'll see if there's some way to have cfengine set that dynamically or something.

    Though should I have cfengine promising all of /etc/make.conf ? There's a block in /etc/make.conf that is the same across all my FreeBSD systems, since its the ports that I come across that don't like 'make -j#'. And, it was intended to have cfengine promise that part, though it there have been other additions that I want the same on all my FreeBSD systems, like the override on modules in net-snmp, that I mention when I ran into some cacti. Though there's value in having cfengine having the whole file....or rather its that the files are in subversion.

    Next up...nagios has alerted me that spamassassin has stopped, yeah, I guess that would happen. Which means there's going to be a big chunk of spam in all my mailboxes (126...I need to find a good way to aggregate them back so that I can read them all ... from roundcube) module rebuilds are done, and spamassassin seems to be running again (probably because cfengine3 has a promise to keep for that) Though might work better if I do an 'sa-compile' to make sure that part is right...though seemed to me it was only major.minor....

    Full story »

    04/28/13

      10:06:00 pm, by The Dreamer   , 989 words  
    Categories: Hardware, Software, Computer, Ubuntu, FreeBSD, CFEngine

    Took a diversion from cacti and now its nagios

    So, doing cacti on cbox doesn't seem to be working long term... but, the moment is being prepared for....I starting to assemble the pieces to build a new machine to do this and handle some other tasks that I've been looking for a place for.

    Back to cfengine, I added a promise for dnetc (distributed.net)....and then a promise to finally configure CUPS on the two servers. And, then I turned to nagios.

    I spent a couple evenings creating the initial configuration of nagios, working in design changes that I wanted to make and initial monitoring of localhost (dbox). Though it wasn't straight forward....there were differences here and there....mostly in FreeBSD layout, paths, and some of the commands taking different options. But, eventually I got everything running. My old check_dyndns worked once, but then stopped working.... problem was that it did 'stat -c "%Y" ..." which doesn't work on FreeBSD, 'stat -f "%m" ...' was the adjustment for that. All, while all the checks_* seem to be there, command definitions was lacking....but I guess having command definitions for everything is part of the debian/ubuntu packaging. There were other frills that came with that, that I don't mind not having...

    I did run into check_ntp being deprecated....with check_ntp_time and check_ntp_peer being the tests to use....separating and making more clear on whether you're comparing time between servers using ntp or checking the state of the ntp server...
    It did show some interesting oddities in holding NTP time on my home network.... I know that I should have 3 or more ntp servers, but it seems that I'm often landing in the state where I only have 2....with lots of delay, resulting in pretty good swings of jitter....almost makes me wonder if this something I could graph in cacti.... &#58;&#104;&#109;&#109;&#58;

    Wonder if I can find a cheap NTP appliance somewhere....

    The last stumbling block was check_dhcp. Which seems to be broken on FreeBSD. All, the discussion on it seemed to point to firewalls, but no firewalls and it still didn't work....tcpdump on both places, and its saying it sending stuff, but no packets appearing on the network. But, I can see the other DHCP traffic on the network.

    I remove that check and call it a night. I mull some possible work arounds....first one I tried was setting up linux compability and try running the check_dhcp from my working (ubuntu) nagios. Well, it didn't work...it couldn't find an interface. Oh well, guess there's the ugly way....use nrpe to invoke it. Though that didn't work right away.....probably because while I had created new nrpe configs for all my servers in cfengine, I haven't put any of my ubuntu servers under cfengine yet. Most of the other promises haven't been implemented for ubuntu yet. It was pretty simple to include nrpe.cfg for everything.... in fact it condensed to only 3 files.... a freebsd version, an ubuntu version and a host specific version for orac. Well, not right away...that happened more recently...while I was going through and updating the nrpe.cfg's by hand on the ubuntu servers. Was when I noticed that some of the files were only different in comments....so I made further simplifications in cfengine...which'll propagate out eventually....

    Long term, I'll probably just have to track down some alternate implementation of check_dhcp....

    I then add cbox to monitoring...and then looked to see about monitoring things that are on cbox/dbox...so I found checks for freeradius, cups, squid, along with improvements to checks on ntp. The check_squid was tricky....I got it working by hand, after making the suggested change for the default Cache type parsing, which turned out to be changes for squid3 vs. squid2 (but box is still running squid 2.7 - since I had re-built it by hand with SSL support, and blocked ubuntu from updating it. Orac wasn't blocked so it eventually turned into squid3.

    it worked by hand, but wouldn't work under nagios...turned out that the embedded perl wasn't liking it. I was going to disable embedded perl for it, when I took a look at seeing what it was complaining about. And, did some reading on embedded perl.... the gist was "use strict", "perl -w" and "perl -c" as starting points. perl -w was find, but perl -c had one problem....which I fixed. But, no go. And, then noticed the line "# todo : use strict", guess I'll have to deal with that.

    And, making that all happy, got it working.

    The only other quirk was the memory check wouldn't work on FreeBSD, I guess there's no mallinfo() available for that. So, no running that test on those servers....plus no Cache test on box. But, it still left enough variety of tests that worked on all. And, it wasn't so much that I wanted to get all the information, but I choose to define all the different tests with ports set into the test....so running the check would also test that all my squid ports worked. There's actually only two that matter, but I have all my squid's configured the same, listening on 5 or 7 ports....depending on whether I have SSL enabled. Though I pretty much only need two now. I'm not doing transparent proxying and I don't need the SSL now that I've split box into dbox/cbox....the SSL was so ddclient could work on box and update dyndns via proxy to DSL....

    Next up is adding zen to nagios, and coming with with more tests of things that are specific to zen, but covered or not covered in the old nagios.

    Though as I worked along...there were things I couldn't find monitors for...though I realized that I could have cfengine promise that those services were running. Plus cfengine was also taking care of other things. So, I should probably work on writing some promises for zen. So, I can have promises to make sure things are started up again after a port is updated or that php/extensions.ini is reordered, etc.

    But, I'll probably continue adding everything else to nagios first.

    1

    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 1 month 1 day 22 hours 57 minutes and 42 seconds until the end of time.
    And, it has been 4 years 11 months 26 days 15 hours 5 minutes and 14 seconds since The Doctor saved us all from the end of the World!

    Search

    December 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: 0
    This seal is issued to lawrencechen.net by StopTheHacker Inc.
    powered by b2evolution

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

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