On Thursday, May 2, 2013 1:37:53 PM UTC-5, Ken Coar wrote: > > On Monday, April 22, 2013 9:48:21 AM UTC-4, jcbollinger wrote: > >> >> Well, no. The Puppet agent does not function as a file server, so you're >> not proposing to make use of anything that's already there. And, even if >> the agent could provide file services, you're still talking about setting >> up an additional server. >> > > So the fact that the 'file server' API is listed under 'Shared master & > agent API' on http://docs.puppetlabs.com/guides/rest_api.html is a > mistake? And no, not an additional server -- just adding functionality to > one of the clients already under the master's ægis. >
Although the 'file server' item is "under" the 'Shared master & agent API' section in that it comes later in the document, it is *part of* the next section, 'The master HTTP API<http://docs.puppetlabs.com/guides/rest_api.html#the-master-http-api> '. The shared API section lists only the 'resource[s]' and 'certificate' verbs. The docs and I are saying the same thing. > > More importantly, you are proposing a dramatic complication of the >> management architecture, no matter how you implement it. You are >> suggesting that the master delegate authority over (some) files and their >> contents to another principal under different administrative control. The >> specifics of how that other principal fulfills that responsibility pale in >> comparison with the fact that the master is performing such delegation in >> the first place. >> > > If that's the rationale, I don't see that the ability to have a FQDN in > puppet:// URIs is meaningful at all. From what you say, the host would > need to be either absent or the puppetmaster, so what's the point? > > Indeed, as far as I am aware, most people do not use an authority component in URIs using the puppet: scheme. I agree that doing so is of limited use, but the URI format permits it. With that said, you could, in principle, set up a separate file server, but it would have to be either another master or a custom server. There might be additional issues to sort out around SSL, but it should be doable. Whether it is *advisable* to do so is a whole different question, however. > And, actually, I don't see allowing my group to directly control our files > to be a complication as much as a feature. According to the docco, the > agent supports being a file server, and the syntax supports a file server > FQDN other than the master's, and the file server would be a peer of the > clients within the cert structure. The alternative (or at least the *main > * alternative) is to push all these files up to the master, and maintain > them there through all their vicissitudes of change. That's extra work all > round, for files meaningful to our group and no-one else. > The agent does not support the feature, sorry. In any case, you and I are talking about altogether different aspects of the issue. You are taking a functional perspective (how do I get my files distributed) whereas I am taking a site architecture perspective (what is the source of truth? who has authority over what?). Inasmuch as you're not in charge of Puppet, that's probably not of direct use to you, other than being somewhat explanatory, so sorry about that, too. > > Using an NFS share or the like means setting up a parallel microcosmic > infrastructure to provide what I read the documentation as saying is > already available and supported in Puppet 2.7, with all the additional > development and maintenance that would entail. > > Of course, if the API documentation is wrong and the agent *doesn't* support > file server operation, I will readily concede that I'm butting at a > windmill. But if the docco is *correct*, I think I'm just having > technical issues -- philosophical questions aside. :-) > > What if the docco is correct and the agent doesn't support file server operation? :-) If I were doing it then my first instinct would not be an NFS share but rather a version-control repository. I'd probably choose git, but if there's another you prefer subversion, mercurial, or whatever then that would be fine, too. Puppet (or even just a cron job) would periodically perform a git pull / svn update / whatever to sync clients with whatever state you are currently publishing. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
