[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
SUMMARY (Re: [SAGE] cfengine install help?)
Thanks to all who replied! There's a stepwise summary at the end of
this post.
On Mon, Apr 12, 2004 at 01:18:44PM -0700, Eric Sorenson wrote:
> On Mon, 12 Apr 2004, Mark C. Langston wrote:
>
> Hi Mark, hope this helps.
Hi Eric! Long time no see! I think it did.
>
> > 1) I know I need to manually execute cfenvd and cfkey on each client.
> > Must I transfer /var/cfengine/inputs/* manually as well?
>
> All you need is update.conf, included with your distribution.
> update.conf always runs first thing upon cfagent invocation, and
> therefore ought to include something like:
>
[...snip]
>
> Your mail suggested you have post-installation-type actions in
> update.conf, which is OK, but those things are doable in normal
> config files too, whereas update.conf is the only place it makes
> sense to download the latest copy of the inputs directory.
>
Yes, but your approach makes a bit more sense. The separation of
functionality among the update.conf and cfagent.conf wasn't very clear.
> > The client accepts the host's public key (per the
> > directive in cfagent.conf, and per the permissions in cfservd.conf), but
> > cfagent always gives "cfengine:: Server returned error: Host
> > authentication failed. " when attempting to transfer files from server
> > to client. It's very much not a name resolution error, cfservd is
> > running on the server, and the pub/priv keys have been generated on both
> > the server and client in question.
>
> This is likely due to confusion in cfservd.conf on the server.
> Here's mine, with caveats post-fix.
>
> ## BEGIN cfservd.conf
> groups:
> # these are hostnames (==always-defined classes) of the servers, for
> # conditional
> cfservers = ( masterserver testserver )
>
> control:
> domain = ( domain.com )
> any::
> IfElapsed = ( 1 )
> # These are the IPs of masterserver/testserver - enables 'cfrun'
> TrustKeysFrom = ( 10.0.0.20 10.0.0.30 )
> cfservers::
> MaxConnections = ( 100 )
> # NB security warning - this is a big convenience tradeoff!
> TrustKeysFrom = ( 10.0.0.0/8 )
> DynamicAddresses = ( 10.0.0.0/8 )
> DenyBadClocks = ( false )
>
> admit: # or grant:
> cfservers::
> /export/home/local/cfengine2/dist *
> /export/home/local/cfengine2/inputs *
> any::
> / masterserver.domain.com testserver.domain.com
> ## END cfservd.conf
>
>
Aha! This seems to work (your version is syntactically different from
the other versions I've come across -- e.g., using CIDR notation rather
than dropping the final octet in the address range, which is what I saw
in examples and what I attempted to use).
The authentication failure seems to be related to a similar problem you
noted in May 2003, where the error seems to be thrown in response to the
code's inability to stat an existing file or directory. Frustrating and
confusing.
> > 3. What I'm not grokking is how the clients periodically pull config
> > changes from the server and execute them, and otherwise execute the
> > stuff in the existing configs.
>
> See 1. above -- this is what update.conf is for.
>
Yep. With the changes to cfservd.conf I've made based on your example,
it's now working.
I think I finally have my brain wrapped around the install process, and
will be writing up a HOWTO today or, more likely, tomorrow. I'll post
to the list the location of the document when I've finished.
In the meantime, here's the very basic sequence:
[NOTE: The following actions should be taken on the host you wish to run
as the cfengine server]
1) Compile and install cfengine (and bdb and the latest OpenSSL if
you're without them). Note that if you don't have a recent texi2dvi
(from Gnu texinfo) and a TeX implementation that plays well with it, the
make install will bomb during prep of the docs (the latest tetex and
texinfo did not work for me on Solaris 2.7).
2) Run /usr/local/sbin/cfagent without options, to get the
/var/cfengine/* hierarchy built automatically.
3) Run /usr/local/sbin/cfenvd
4) Wait about a week if you have no /dev/random or /dev/urandom, then
run /usr/local/sbin/cfkey (or just run it without waiting, if you're
okay with a very low-entropy key generation).
5) mkdir /var/cfengine/inputs
6) create /var/cfengine/update.conf and /var/cfengine/cfservd.conf
(Eric's examples above are good for starters)
7) execute cfservd , and correct any errors if it bails.
8) execute /usr/local/sbin/cfagent -v -n and check the output for
errors. If you want, go ahead and run it again, omitting the -n.
Now, on to the clients you wish to bring up (assuming they're hosts that
are already built and running):
1) Somehow get cfkey, cfenvd, and cfagent onto the clients. I did it
via a routine rsync to the hosts in question. You could just manually
copy them over.
2) Execute steps 2-4 above on the clients.
3) Execute step 8 on the clients.
Now, you're ready to set up cfagent on the various hosts (server and
clients) to run periodically (if your cfagent.conf doesn't already do
this for you). I have in my cfagent.conf:
editfiles:
# Make sure cfexecd runs hourly from cron too
{ /var/spool/cron/crontabs/root
AppendIfNoSuchLine
"0 * * * * root /usr/local/sbin/cfexecd -F"
}
(note: cfexecd is a local wrapper for executing cfagent)
Now, assuming that cfagent's running properly on both server and
clients, any changes you make to /var/cfengine/inputs/cfagent.conf (or
update.conf, or cfservd.conf) should get noticed by the clients, pulled
down, and run. This includes directives to check on processes and
restart them if necessary, copy files from point to point, edit files,
move/remove files, stop processes, and so on. Hence the power of
cfengine in widescale deployment: change one config file to effect
widespread changes on multiple hosts on a pull rather than push basis.
--
Mark C. Langston Sr. Unix SysAdmin
mark@bitshift.org mark@seti.org
Systems & Network Admin SETI Institute
http://bitshift.org http://www.seti.org