Anyone who has ever administered a Cisco Unified Communications Manager (AKA Call Manager, or CM) system learns very quickly that there are approximately 17 billion different configuration settings in CM. All of those configuration dials have to be maintained in the right ways to get the system to do what you want.

I've taken several Cisco training courses on CM, and I felt like the thing that was missing was a real-world case study of how you setup all the pieces to interact with each other and why. There was no real "best practices" in the classes, just a lot of "this setting does X or Y" without any explanation of why you would choose to do X vs Y.

Read on for exactly that information from documentation I've been working on for the CM environment at my job.

I'm teaching on LDAP at SCaLE U today, so I've uploaded my slides in advance.

At $WORK, we currently use cfengine 2 to manage on the order of 300 systems. It works, it does most things we want. We use the Singlecopy Nirvana "pattern" to distribute configuration files of all types, have copious shellcommands, and even a few editfiles. In general, it does what I need, but not necessarily the way I want. The general structure of our cfengine configurations is (for the most part) unchanged since I implemented it ~4 years ago. We've done the necessary things to support new OS's, new architectures, what have you, but that's about it.

Like probably almost anyone reading this blog, I'm a sysadmin. Specifically, I consider myself to be a pretty darned good one - years of experience, blah blah blah. One of the personality traits a "good sysadmin" has, is the drive and ability to learn new things. COMPLICATED things. No fear. Try out installing and setting up high-availability linux clusters without ever having done it before, try implementing SSL in apache, etc-- you just roll up your sleeves and go. You'll stumble, but you'll LEARN. And you become a rockin' sysadmin in the end because of it.

Lately, I have been wrestling with being able to do that any more. Specifically, the office in which I work has been reclassified as a "service center" of sorts. We have tons of campus customers, and we now charge back for our time. Which means *I* have to charge back for my time. It's a result of the current economic situation, everyone needs to do what they can to survive.

OK, not related to work, but worthy of a blog entry at least.

The other day I dove into VOIP for the first time. I admit, I'm a bit of a holdout with regards to my home phone service. I'm also old enough to recall the days when the phone in our house plugged into the wall with that huge 4-prong plug, and Ma Bell engineer(s) needed to do ANYTHING with regards to phone jacks or phones. If you so much as clipped a wire, out came the Bell-Police :-) Getting to the point of cutting my AT&T service is emotionally difficult. I've ALWAYS had AT&T.

Anyway, I finally decided to switch to VoIP and cut my land line. I'm not there yet, as I'm currently testing out the device first. I opted for an "ooma", which is essentially a product that's "VoIP in a box". You pay for the unit (about $200 US), and that's it. Everything else is free for as long as you own the unit. No monthly charges, no fees, no regulatory charges, nothing. Free local calls, free long distance. And they support porting your land-line number to the device when you're ready ($40 fee).

Just submitted an article on Cfengine 3 to http://sysadvent.blogspot.com/ - I guess it'll be a few days before it's posted.

Like many of you, I like to have some of the latest technology at my fingertips. Specifically, I'm talking about my workstation. No, while I don't have über-fast sexy hardware, I like to at least have the latest OS flavor(s) installed so I can play with new features.

The other day I decided it was "time" for Fedora 12. Time to play with ext4.

Before I begin, a small word about my prior setup:

disk 1: Windows XP, NTFS partition. Old, crusty, not used anymore, as I have XP in a VM now.
disk 2: Fedora 11, Linux LVM partition. No real data of value, but it does house my XP vm.

I use OpenBSD's packet filter, PF, and am in the middle of building a new router/firewall with a moderately complex ruleset. I generally code rulesets the same way I write shell scripts: adding small bits and testing. My basic ruleset was preventing routing, and the logs kept telling me that the routing packets were being blocked by a rule that I thought shouldn't.

PF has a feature called "antispoof" that builds a set of rules that block packets that claim to originate from interfaces they shouldn't. The rule looks something like:


@16 block drop in log on ! vlan1 inet from 192.0.2.0/24 to any
[ Evaluations: 9907 Packets: 9283 Bytes: 794994 States: 0 ]
[ Inserted: uid 0 pid 2131 ]