This is part Two of an N-part series (I'm thinking 4 parts) discussing the investigation of radmin as a patch/deployment tool for FreeBSD. It will be filled in over the course of Q2/2009 as we test (and possibly deploy) radmin at Premier Heart.
This part deals with some more basics: Creating an radmind "Base Load" to distribute to your machines.
The radmind Base Load is the template that will be deployed to all servers and consists of Three major parts:
A "Positive Transcript" (often just called a transcript), which lists files and directories to be included in radmind deployments
A "Negative Transcript", which lists files and directories to be created or adjusted, but not replaced by radmind deployments
A "Defaults Transcript", which is a special case of a negative transcript.
This is part One of an N-part series (I'm thinking 4 parts) discussing the investigation of radmin as a patch/deployment tool for FreeBSD. It will be filled in over the course of Q2/2009 as we test (and possibly deploy) radmin at Premier Heart.
This part deals with the basics: Getting radmind up and running on a FreeBSD system.
radmind is not a complex system -- It doesn't require anything beyond a basic FreeBSD installation to run, and as a bonus it's in the FreeBSD Ports tree / package collection.
I'm using the package, and you probably should too. The package can be installed on any fresh naked FreeBSD system, at which point you can use it to apply the radmin transcripts to the naked machine and deploy your custom installation. No fuss, no muss, and most importantly it's FAST.
I'm not going to get into how to install FreeBSD packages - If you can't figure that out you're not ready to be reading this. Go familiarize yourself with the FreeBSD Handbook and get some real-world experience, then come back. If you're back in less than 3 months go get some MORE real-world experience - I promise you you don't have enough yet.
Continue reading "Managing Multiple FreeBSD Machines with radmind -- Part One"
This is part Zero of an N-part series (I'm thinking 4 parts) discussing the investigation of radmin as a patch/deployment tool for FreeBSD. It will be filled in over the course of Q2/2009 as we test (and possibly deploy) radmin at Premier Heart.
As many (if not all) of you know, I'm a BSD Bigot - I firmly believe that the BSD projects have a huge edge over Linux on servers in all the areas that matter to me most: Performance, Security & Stability. That being said, there's one area where they suck big floppy donkey dick: Patch Management.
Over the years I've had several solutions:
Ignore the Problem Don't patch and hope you never get compromised. This has never been an acceptable solution to me.
Patch Manually Log in to every machine in your organization once a quarter, do a Make World / Portupgrade and deal with the fallout. This is great if all you have are 1-2 machines, and it's how I patch bsd-box.net.
Deploy a Build Server A central machine builds the world and ports, then you log in to each machine to install them. It's manual patching, but you don't wait for Make World to run a bunch of times. This is what most BSD admins do, but I'm lazier than the average admin.
Deploy a Commercial Solution This is OK as far as it goes, but using commercial solutions puts you on someone else's patch schedule. Also, I'm not aware of any commercial solutions that Don't Suck™.
Use freebsd-update While I greatly admire what the FreeBSD Security Team has done with freebsd-update, it's just not for me -- Patching my custom software and ports with freebsd-update is a pain in the ass (I would have to essentially roll a custom release - More work than I want to do.) Also, freebsd-update is geared toward applying the security team's patches, not managing system deployments - that's only half of what I want.
None of these solutions work for me, so for the last 3 years or so I've been trying to find one that does. I've examined a few options, from the traditional "let a junior admin do the patching" through writing a remote execution program to handle it. None of these give me what I need: A simple, straightforward way to go from configuration X to configuration Y without breaking anything.
Continue reading "Managing Multiple FreeBSD Machines with radmind -- Part Zero"
OHAI! Long Time No Blog!
I've been inspired by this post over at AppleInsider, titled "Apple details compatibility issues between iWork '08 and '09". Here's the gist:
Apple has acknowledged a problem with its productivity suite, iWork, in which the previous version known as iWork '08 cannot open files created by iWork '09.
Posted earlier this week, the support article advises users of a workaround but makes no mention of any forthcoming corrective updates to iWork '08. The latest version, iWork '09, was unveiled at Macworld last month with updates to Keynote, Pages, and Numbers along with a new online service called iWork.com.
Apple instructs users to save their documents as iWork '08 files if they need compatibility with the older version. While Apple used Keynote '09 as an example in the screenshots, the same issue affects the entire suite.
This is part Two of an N-part series (I'm thinking 4 parts) discussing the investigation of radmin as a patch/deployment tool for FreeBSD. It will be filled in over the course of Q2/2009 as we test (and possibly deploy) radmin at Premier Heart.
This part deals with some more basics: Creating an radmind "Base Load" to distribute to your machines.
The radmind Base Load is the template that will be deployed to all servers and consists of Three major parts:
