On 2/9/10 9:11 AM, "Tim Cutts" <t...@sanger.ac.uk> wrote: > On 9 Feb 2010, at 4:59 pm, John G. Heim wrote: >> I have a couple of problems the biggest is that I don't know how to >> get the >> cfengine server to know that when I'm doing a reinstall, it has to >> accept a >> new key. When I run cfagent on the new install, it generates an error >> message that says the keys don't match. If I delete the key from the >> server, >> it works. I guess I'm asking how to break the security on cfagent >> just for >> reinstalls. >> >> The second problem is that only some of the packages get installed >> when I >> run cfagent on the client. If I run it 3 or 4 times, eventually, >> they all >> get installed. Perhaps this is an apt system question but I was hoping >> someone on this list had dealt with this problem before.
It could be an apt thing -- I've seen similar behavior with FreeBSD and meta ports with gigantic dependency lists that cause pkg_* to bail in interesting ways. I think you're ultimately hitting some sort of failure that can't be resolved in the default number of passes, so it takes multiple runs to fully correct the situation. Manual runs should show a gradual progression to all promises kept. In this case, I would generally "let things converge" or write a module which does the right thing for packages (checking for failures) and outputs various classes and macros cfengine can use to better understand status and respond. > 1) This version will make the security people scream: have all FAI- > installed machines use the same key. A reinstallation doesn't cause a > problem then. Since only FAI can put the key there, you'll still > notice if someone reinstalls the machine some other way, so it's not a > *total* security disaster. In our case, our FAI config server and our > cfengine policy server are [usually] the same machine, so any key it > puts in place ought to be trusted. Yeah -- I was asked to do this and refused, it just feels dirty doesn't it? InfoSec doesn't like it. > 2) Put some hooks into FAI so that very early in the process, before > the filesystem is recreated, you mount the old root fs, temporarily > make a copy of the key files in the tmpfs /tmp, and then put them back > after the machine has been rebuilt. This is the option we took in our net-installs, and I highly suggest pursuing it. We have our net-installs preserve a number of "useful" things from the system "when appropriate". > The FAI people, if you ask them, will almost certainly tell you not to > reinstall machines, but to use softupdate instead. If it's the same > machine, then softupdate should be all you need to keep it up to > date. If it's a reinstall, then it's arguable that it's no longer the > same machine, and it's correct behaviour to change the host keys. This is true... Which is why to properly implement this "preserve data on rebuild" feature, one should really have an external state tracking system (e.g. inventory database) that has some notion of a system's "purpose" (or cfengine role) regardless of hostname, IP, etc. Then you only keep old data when the host's role hasn't changed. If you want a more lightweight approach, and really don't care that new keys are generated on each install (why should you really, it'll JFW like re-generated SSH host keys), then it should be a simple matter to tie a ssh key into your net-install process that allows clients to remove keys from your policy host(s) matching their own IP. This is the kind of thing to research now and get right from the start... Then people will love you later. If you're pushed to implement an easy solution when you truly feel more is required, ride the technical debt wave: http://blogs.construx.com/blogs/stevemcc/archive/2007/11/01/technical-debt-2 .aspx _______________________________________________ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
