(message trimming for sanity going on) On Sat, Sep 25, 2010 at 3:41 PM, Luke Kanies <[email protected]> wrote:
>> Completely a security issue. > > And you don't even want the facts downloaded to a client that won't use them, > or you don't want them run on a client that doesn't need them? The latter. I don't want the code executed. >> I'm not entirely sure. I've been thinking this through a lot lately, >> and I honestly can't think of a great way to resolve this in a single >> run other than the external node classifier setting the modulepath and >> manifestpath and killing the use of environments altogether. (when you >> have a hammer...) >> >> One possible option would be (and I'm not entirely opposed to this) to >> have two puppet runs. >> >> 1. a 'prerun' environment that syncs facts, takes parameters from >> external node classifer and writes them to disk >> >> 2. The normal puppet run syncs all the shared facts to the client, >> plus a special fact that reads the results of the first run, and the >> other facts are all set to be confined on this special fact. >> >> ie your external node definition has: >> >> parameters: >> - enable_fact_foo: true >> >> and the foo fact has: >> :confine enable_fact_foo => true >> >> That way the people sharing the modulepath have to explicitly choose >> to enable any fact from their shared code base, and you enforce the >> presence of such confine statements in the pre-commit hooks. >> >> This doesn't do anything to solve the problem of non-fact plugins, but >> honestly in this case I would simply deny those based upon a >> pre-commit hook and only allow modules/*/lib/facter > > I think this is essentially too complicated to be useful in practice, and > also not a sufficient enough solution to really make you happy anyway. You'd > always have this bicameral system where some facts were more equal than > others, so to speak. Ah, but if you *also* use this pre-run environment to do your provisioning... the cost may be worth it. I'm perfectly ok with having a core set of facts that are indeed more important than the rest. >>> We've shifted away from having a separate directory for facts and Puppet >>> code, but this implies we should not have done so. >> >> I wouldn't go that far. As you say, I'm the first person to bring this >> up, and we absolutely needed a way to make modules truly >> self-contained, including facts/plugins. Pluginsync and >> plugins-in-modules resolved a lot of the crufty issues we had around >> factsync and environments. > > That's good to hear, anyway. > > I dunno know if this helps, but let me walk through one of the changes I'm > hoping to make soon and maybe you can tell me if you see a way this could > help. > > Basically, I want to (at least optionally) split what is currently the three > step agent run (upload facts, download catalog, run transaction) into > separate steps, where the fact upload is a 'registration' process. This > would, at the least, allow you to develop more control in that process, where > currently it's a bit thin. Absolutely. I've considered several hacky ways to accomplish the same thing. (pre-run command for puppet that runs puppet with a different config file and a lightweight registration environment) > This doesn't solve anything per se, and we'd need to also reify the 'update > plugins from server' process as a separate step, but possibly treating one of > them separately, and giving it separate controls, would give us the > flexibility and clarity to do figure out what to do. > > My intuition says that the right direction is making more defined steps and > providing much more clarity on what those steps can do and what they require, > rather than making the existing system more complicated by repeating steps or > having any given step get more complicated. Possibly. I think I'm with you. My intuition leads this way, but I'm not sure if I'm ignoring a fundamental problem or not yet. >>> The only short-term way I can see of solving this is to use the node >>> classifier to figure out what classes are used, map those classes to >>> modules, and only include the appropriate code from those modules. That >>> doesn't really work, though, because there are always going to be classes >>> included by those specified classes, and their code won't be sent to the >>> client, which is a problem, along with the resource types and such that are >>> outside of classes but are used by required classes. >>> >>> Another (not very good) option is to record which modules are used from the >>> last compile and send the code down for the next one. This doesn't work >>> for somewhat obvious reasons. >>> >>> The only reasonable option I can think of requires us to separate facts out >>> again. I don't think there's a way around sending all facts to the client. >>> If we do that, though, then we can wrap the rest of the plugins in with >>> the catalog, just like we do for files here: >> >> Yeah, these are the options I've come up with so far that I've >> rejected as being incomplete and/or complicating the client run >> significantly. >> >>> >>> http://projects.puppetlabs.com/issues/4817 >>> >>> In that model, maybe we automatically create a 'plugins' stage that goes >>> before any of the existing stages and add a file resource for each of the >>> modules we are using. Again, this doesn't really fix it for you, because >>> your facts are still combined, and they all have to be maintained separate >>> from the rest of the ruby code, but it gets you close. >>> >>> The only other option I can think of, and this is something that multiple >>> people at Puppet Labs want but is very far away, is to have partially >>> compiled catalogs that resolve as much as possible without having the >>> facts. I'm not actually convinced this is possible in anything resembling >>> a reasonable way, but even if it is, it's far enough away that you >>> shouldn't bank on it. >> >> I'm not quite convinced it's possible either, but I've dreamt of this too... >> :) >> >> Thinking about this issue in conjunction with the feature request for >> Puppet to understand package dependencies natively does make me wonder >> if we need to aim for a more dynamic system than our current catalog >> can provide. > > The packaged dependencies don't really affect the complexity of the catalog, > IMO - the complexity there is about how the catalog is updated by the > transaction. The bog-standard catalog semantics work fine, it's just the > update rules that don't really. To clarify, you're saying the catalog won't really include all the implicit relationships delivered by the packaging system, but as individual resources are applied, those relationships will be included? Or are you still talking about the idea of uploading the packaging relationships at the start of the run? I feel that last idea is ultimately doomed, as we make many many changes during our runs that affect these relationships in a significant manner. Adding repositories, changing pinning, etc etc. -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
