Building a Linux infrastructure with maximum automation |
 |
By Leah Rosin
26 Jan 2009 | SearchEnterpriseLinux.com |
|
|
Nate Campi and Kirk Bauer have updated their book Automating Unix and Linux System Administration, which covers Unix and Linux system automation basics with a new focus on using cfengine for the task. We asked them a few questions about the new edition to give you a taste of what the book will focus on and provide some helpful insight into the process of automating Linux adminstration on your system.
What's new? What were the areas you updated from the first edition?
Kirk Bauer: The second edition was more of a rewrite than a revision. This edition attempts to demonstrate how to build a UNIX/Linux infrastructure from scratch with the maximum amount of automation (almost total). We felt that there weren't enough examples of how to do this in the real world.
We are also believers in the philosophy that people learn best by doing, so we wrote it in a way that's easy to follow along with. System administrators new to automation, or those that need to build a new infrastructure can follow along with the book and build a fully automated infrastructure of their own.
Who do you imagine (or know) your readers to be? In other words, who do you think will be most interested in this book?
Bauer: This book is most useful for the mid-level SA looking to advance into automation and infrastructure building or advanced SAs looking to learn cfengine.
We don't think any of the automation concepts are beyond novice SAs, but the book doesn't teach basic administration concepts, i.e. shell scripting or how System V init scripts work. The book simply uses shell scripts and init scripts and assumes that the reader can follow along.
Nate Campi: I agree with the target audience from a technical perspective. In terms of the type of person, we expect our readers to be current systems administrators, architects, or even management, who have a thirst for efficiency, consistency, and reliability. The kind of person who has been thinking "There has to be a better way to do all of this work"... that is our reader.
It is quite a project to automate Unix or Linux system administration, in today's tight budgets, many IT admins might be interested on the ROI on such a project. Can you share any insight as to how long the automation process takes versus the time savings/cost savings once it is complete?
Bauer: We think that there are two key considerations:
- Time savings -- Automation systems have overhead, but in our opinion this overhead is easily offset in time savings when changes need to be rolled out to many systems in a reliable manner (new software deployments or updates, for example). When using cfengine (or for that matter most automation systems) the SA staff don't need to control all aspects of the system with automation, they can choose only to implement new changes using it. This gives immediate benefits without any drawback beyond deployment of the automation framework itself.
- Technical advantages -- Many things are difficult or even impossible without an automation framework. Compliance efforts are much easier to deal with when a regularly running automation system ensures compliance with policy and reports on system state. Another key technical factor is scale: ad hoc measures don't scale well when dealing with hundreds of systems, and break down completely when dealing with thousands of systems.
Automated system adminstration results in more reliable systems that require less administrator time for mundane tasks. There are very real
time savings, but the specific savings depend on the framework being used and the task(s) being performed.
Campi: Let's say I have a task that I believe I will only do once or twice and I could spend 10 minutes automating it or 5 minutes doing it manually. Have I wasted time by automating? I don't think so. Not only have I accomplished the task, but I have accomplished it 100% consistently in all cases, where manual changes have a tendency to be inconsistent. In addition, you inevitably find out that you need to do it again one day. Will you remember how to do it two years from now?
If you automated it, you also documented what you did for future reference (or, more likely, the automation will just automatically apply). I believe that automation leads to more consistency, better documentation, and fewer errors/mistakes. You only have to make a few mistakes or have to re-learn the same thing a couple times before automation becomes a no-brainer.
Chapter 3 is about using SSH to automate the system securely. How important of a consideration is security when considering an automation effort? What are the areas that need special attention or that have particular vulnerabilities in an automated system?
Bauer: Security is especially important with automation systems because of the trusts required in such a system. These trusts need to be analyzed carefully. You need to understand any exposure that could result from an attack over the network as well as one from a user with a shell account on your systems (such as a compromised user account). Central points of administration are also logical points of compromise for an attacker.
This is one of the reasons why we used the cfengine framework, because it uses strong two-way RSA authentication and has strict default-deny access controls in its file server daemon.
Chapter 10 focuses on monitoring. What should a Linux admin be looking for in an automated system admin set-up? What are the big things to watch for?
Bauer: A Linux admin should be looking for a few key items in an automation system:
- A proven track record: Are people using it to do the job that you want it to do? Don't be a guinea pig for some new open source or commercial software, since automation framework deployment and usage is a difficult enough job without debugging the automation software itself. Cfengine is a proven framework that has been in use at large sites for 10 years or more.
- Security: are the trusts in the system minimized, strongly authenticated and access controlled? Further, does the framework have a record of repeated security problems? As previously discussed, cfengine is a good choice here.
- Ease of maintenance: is the system itself easy to use? It will only be deployed once, but will be in use for a long time afterward. We consider a system with difficult deployment but easy maintenance to be an acceptable compromise. We consider cfengine to be easy to maintain due to its simple syntax, and deployment is quite easy.
The publisher has provided a free download of Chapter 1, which is available on SearchEnterpriseLinux.com with a review of Automating Unix and Linux System Administration, second edition.
|
|
|
|
