Re: Bootstrapping

[Eric Sorenson]

On Mon, 16 Feb 2004, Luke A. Kanies wrote:

> Hi all,

Hi Luke, thanks for this great post -- My butcherous snippage is
purely in the interest of brevity and should not be construed as
any comment on the parts thus removed.

Environment note:
I'm running cfengine2 across about 700 RedHat-7.3 based systems.
It's used primarily for copy: of CVS-controlled files off the 
master server, along with a few miscellaneous tasks (post-OS-install 
customisation, mostly). The files are various system daemon configs
that change more rapidly than justifies a new RPM version, but don't
require immediate network-wide propagation.  For instance, nsswitch.conf
and printcap are under cfengine control, but password / uid lookups
point directly at LDAP.

> [ Binaries ]
> This is a classic package management problem.  If you're not using
> cfengine for package management, then use your normal package management
> solution to get the package installed.  If you are using cfengine, then
> you're in an interesting catch-22:  How do I install the package used to
> install packages?

Not using cfengine for package management. I made a home-rolled RPM
which includes the binaries and the latest update.conf. Part of the
post-install runs 'cfagent -q' so cfenginization happens at RPM
installation time.

> [ Server allowing IP access ]
> How are other people solving the 'random list of IP addresses' to import,
> especially with long lists that change regularly?

Do not have this problem; all my hosts are internal-only
so cfservd on the master has

control:
  cfservers::
      TrustKeysFrom = ( 10.0.0.0/8 )
      DynamicAddresses = ( 10.0.0.0/8 )

> [ Public Keys ]
> 
> Trusting both ends of the connection is one mechanism for solving this
> problem, and it might be that it's the best mechanism.  After all, once
> the keys are set through trust on the first connection, trust is no longer
> used, so it's probably fine.  Is that what most people are doing?

See above; yes.  Trust is predicated upon physical access to the LAN.
I don't really trust cfengine's trust models anyway and probably wouldn't
use them even if I had a cfservd outside my firewall. I'd use
router ACLs upstream of the cfservd host and iptables on the box itself
to only permit known-good IPs. 

> could have a script tailing the syslog output on my server, waiting for a
> failed connection, and then kick this script off if I get a failed
> connection.  Is anyone doing this?

(I hope not) 

> Granting Access:
> 
> My current client has an astounding 20 subdomains with Unix machines in
> them.  They are trying to consolidate, but...  For granting, I currently
> just list all of the granted subdomains, even though that often paints too
> broad of a stroke.  This list fortunately doesn't change much, so it's
> pretty easy to maintain, once you get it working.

I guess it all comes down to -- as Morcheeba asked -- "who can you trust?"
What is your exposure if, through public key or DNS spoofing, a baddie
gets to pretend the machine he's on is an authorized cfengine client? If
you have your /etc/shadow file in the copy: payload, pretty high. If
you have server configuration files or processes/tidy type actions, the
worst that will happen is he's got a nicely configured machine. 

I exaggerate, of course, but seriously -- seems to me the risk is much
higher having unfirewalled, non-chroot/privsep daemons that are 
potentially exploitable to get local root shells, than anything happening
within the framework of known-good, expected cfengine actions happening
to stray hosts. 

All of which is a long-winded justification for why I have turned off
the key checking for all my hosts.

> [Client having a copy of update.conf]

No commentary here, it's just a package management thing. update.conf
never changes and updates itself anyway, so at most you might
have to run it twice.

> [Domain agreement]
> 
> This is an often annoying requirement. 

'nuff said.

> Anyone else have any stories of how they bootstrap their cfengine clients?
> How do you solve the above problems?  I hope to incorporate some different
> ideas and solutions into my article, so give me anything you think
> cfengine newbies should know about.

Look forward to reading the article, thanks for taking the time to do this
survey too. It's helpful to re-examine your underlying assumptions from
time to time to make sure they're, if not totally rational or 'best' in
some objective sense, at least internally consistent in their insanity. :-)


-- 

    Eric Sorenson - EXPLOSIVE Networking - http://explosive.net