www.delorie.com/gnu/docs/cfengine/cfengine-Tutorial_80.html   search  
 
Buy GNU books!


GNU cfengine

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

7.3 Automation

Even in the smallest local area network you will want to build a scheme for automating host configuration and maintenance, because networks have a way of growing from one host into many quite quickly. It is therefore important to build a model which scales. A major reason for using cfengine is precisely for scalability. Whether you have one host or a hundred makes little difference. Cfengine is instructed from a central location, but its operation is completely and evenly spread across the network. Each host is responsible for obtaining a copy of the network model from a trusted source and is then responsible for configuring itself without intervention from outside. Unlike some models, cfengine does not have to rely on network communication or remote object models.

We also need integration, or the ability to manage the interrelationships between hosts. It is no good having complete control of one important host and thinking that you are secure. If an intruder can get into any host, he or she is almost certain to get into the ones that matter, especially if you are not looking at all of them. Using cfengine is a good way of forcing yourself to formulate a configuration/security policy and then stick to it. Why cfengine? There are three reasons: i) it forces a discipline of preparation which focuses you on the problems at the right level of detail, ii) it provides you with `secure' scalable automation and a common interface to all your hosts, and iii) it scales to any number of hosts without additional burdens. We'll need to qualify some of these points below.

The first step in security management is to figure out a security policy. That way, you know what *you* mean by security and if that security is breached, you will know what to do. In many cases you can formulate a large part of your security policy as cfengine code. That makes it formal, accurate and it means that it will get done by the robot without requiring any more work on your part.

As an immune system, cfengine will even work fine in a partially connected environment it makes each host responsible for its own state. It is not reliant on network connectivty for remote method invocations or CORBA-style object requests as is, say, Tivoli. All it needs is an authentic copy of the network configuration document stored locally on each host. If this is the case, a detached host will not be left unprotected, at worst it might lag behind in its version of the network configuration.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

  webmaster   donations   bookstore     delorie software   privacy  
  Copyright 2003   by The Free Software Foundation     Updated Jun 2003