michaelanthoni.com

Well I’ve been using cfengine for a number of years now and thought I had paid my dues already when I initially took on its steep learning curve… Well today I had a little run in with cfengine that made me feel as frustrated as when I was a newbie to this software, but I guess it was a newbie mistake that Im sure I learned years ago that I just happened to forget over the years when adding a cluster of new hosts to the mix - reverse dns.
The issue came about when I was configuring a new group of servers. I was on the final one when I simply installed cfengine on the host, scp’ed over cfagent.conf, cfservd.conf, and update.conf from a host that I had just been successful with. But after running “cfagent -v” i ran into the familiar “Can’t stat /var/lib/cfengine… in copy” which struck me as odd because it had just worked on all the other hosts. After checking the usual suspects such as the grant: function in the cfservd.conf to make sure permissions were explicitly granted on the server side, the hostname and domain name configured on the client, typos, cfkeys, cfservd started ?, etc, nothing seemed to work and adding the debug options -d seemed to frustrate me even more. As a last resort I took a packet capture to see what was going on between the client-> server for both the system that was failing and one that was working. I didnt think it would help much but sure enough after crawling through the capture packet by packet I seen the issue in one of the packets data field that looked something like this…

CAUTH IP IP user - non-working host
CAUTH IP hostname user - working host

This is when the little cfl lightbulb went off in my head and I decided to have a look at reverse dns. Sure enough all the hosts had reverse dns configured but this last one.

Although other functions such as directories,files,editfiles seemed to authenticate and run fine without reverse dns it seemed the copy function was failing because authentication under cfservd and the grant directive is based on the domain *.domain.com and not the IP… sheesh… it seems the parameter SkipVerify can be applied globally here and workaround hosts not having reverse dns, however I decided not to use this option since we control the reverse dns and it really should of been configured, not sure why it was not…

as soon as I added the reverse dns for the host cfagent ran without a hitch…

OpenBSD 4.3 was publicly released on schedule last week with astonishing amount of improvements, new features, and bug fixes. Hats off to the OpenBSD Developers that are putting out some great work to make a stable and reliable product.

However, I must say, I did notice some bug fixes in the changelogs that I’ve actually came across and been caught up on that were fixed in this release. These issues had been referenced in the openbsd mailing lists by other users but were never acknowledged by the developers leaving me frustrated and at a dead end without getting into the code. Its good to see these issues finally acknowledged in the changelog.

Well Openbsd 4.2 has been out for about two months now and I wanted to post this a little sooner but with all the holidays I havent had a chance.

If you’ve upgraded to 4.2 then you have probably ran into the libexpat dependency issue like the rest of us. For those of you who have not upgraded yet, I hope you would read the Upgrade guide as one would expect as this issue is described here.

If you havent read the “gotchas” section, the issue is that the libexpat library has been moved from the base set to the xbase set. Now this presents a problem for people such as myself who do not install the xbase on firewalls and routers. The main problem is that this library is a dependancy to many other packages and is acknowledged with the following statement:

This will impact a large number of users! This was an unfortunate decision whose ramifications were not recognized earlier in the process. For 4.3, libexpat will be part of base43.tgz, solving this problem.

I believe this issue has already been resolved in the -current tree but for those of us who are only running stable we cannot wait the 4 months until the next release cycle and we sure as hell are not installing the xbase set. So what are we to do. I’m sure this is completely unsupported by the OpenBSD folk but this worked fine for me.

Workaround:

Download the xbase set at ftp://ftp.openbsd.org/pub/OpenBSD/4.2/i386/xbase42.tar.gz

Extract the xbase42.tar.gz to a temporary location, say /tmp

#mv xbase42.tar.gz /tmp
#cd /tmp
#tar -zxvf xbase42.tar.gz

There are 3 files in which you need inside the ./xbase42/usr/X11R6/lib directory.

#cd ./xbase42/usr/X11R6/lib
#ls -al libe*

-rw-rw-rw- 1 user group 153436 Aug 8 23:03 libexpat.a
-rw-rw-rw- 1 user group 157767 Aug 8 23:03 libexpat.so.8.0
-rw-rw-rw- 1 user group 183510 Aug 8 23:03 libexpat_pic.a

Copy these 3 files to your /usr/lib directory.

#cp libe* /usr/lib

And whala! A stupid simple solution to a really annoying issue. Now you should be able to install/upgrade your packages as you need without hitting this dependency issue. Other then this little bug the Openbsd 4.2 release has worked great for me.

With that said… (see previous post)

I use Windows XP Pro as my desktop operating system of choice and haven’t seen the reason to make the move to Vista yet, although I will be investigating more in the near future with Windows Server 2008 looming around the corner. I find myself to be more efficient and comfortable, in a windows desktop environment than I do in either GNOME or KDE, although I feel right at home in a GNOME enviornment. Although Mac was probably the first OS I ever used, I grew up using W indows and it feels like home to me. However, I do tend to run unix-like virtual machines on top of my desktop to allow me some flexibility. Also, I run a dual booting, Windows XP/linux configuration on my laptops. Never know when your gonna need what. I like to keep my options open.

I have run a MacOSX laptop in the past but at the present I have not had the luxury.

On the server side of things, I run both Windows and Unix-Like, depending on the situation, client, customer, requirements, etc. On the Windows side I run Windows Server 2003, of course, in its different flavors. On the Unix-Like side my Linux OS of choice for production is Debian, however I am a linux hobbyist and have ran most major Linux flavors including Ubuntu, Slackware, Gentoo, Suse, and Redhat based operating systems at one point or another. My BSD of choice for servers is FreeBSD, but I use OpenBSD for the network infrastructure such as routers and firewalls.

Again, I have closed commenting on this page as to not insite a flame war. This is what I run.

I figured I’d start my first blog postings with some of my ideologies. One of the most fundamental ideological rifts is in the operating system of choice among IT veterans. Mainly Microsoft vs Unix-like. I say Unix-Like because of the many “Unix-Like” platforms we have to choose from nowadays, from Linux to the BSD’s to the Mac OSX, each with there own unique characteristics, pros, and cons, but all essentially “unix” minus the trademark.

I use both Microsoft and Unix-like operating systems as do a lot of us, so its hard for me to choose one over the other, maybe impossible. Its almost as if one of my children asked me who my favorite child was. I would lie and say I have no favorite, even if I did. Although one may give me less headache and grief, I can’t function without either. They both have a place in my world.

As I would not like to be host to a flame war, I have closed commenting on this post. This is my ideology, not yours.