[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bootstrapping
From: |
Eric Sorenson |
Subject: |
Re: Bootstrapping |
Date: |
Wed, 18 Feb 2004 12:23:00 -0800 (PST) |
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
- Re: Bootstrapping, (continued)
Re: Bootstrapping, Nate Campi, 2004/02/18
- Message not available
- Re: Bootstrapping, Nate Campi, 2004/02/18
- Message not available
- Re: Bootstrapping, Nate Campi, 2004/02/18
- Re: Bootstrapping, Erik Hjelmås, 2004/02/18
- Message not available
- Re: Bootstrapping, Nate Campi, 2004/02/18
- Re: Bootstrapping, Mark . Burgess, 2004/02/18
- Re: Bootstrapping, Nate Campi, 2004/02/18
Re: Bootstrapping,
Eric Sorenson <=
- Re: Bootstrapping, Luke A. Kanies, 2004/02/18
- Re: Bootstrapping, John Sechrest, 2004/02/18
- Re: Bootstrapping, Luke A. Kanies, 2004/02/18
- Re: Bootstrapping, John Sechrest, 2004/02/18
- Re: Bootstrapping, Mark . Burgess, 2004/02/18
- Re: Bootstrapping, John Sechrest, 2004/02/18
- Re: Bootstrapping, Luke A. Kanies, 2004/02/18
- Re: Bootstrapping, Luke A. Kanies, 2004/02/18
- Re: Bootstrapping, John Sechrest, 2004/02/18
- Re: Bootstrapping, Luke A. Kanies, 2004/02/18