Jira (PUP-3547) File Server Mounts Should Support Directory Environments

[Joshua M. Keyes (JIRA)]

Title: Message Title

Joshua M. Keyes commented on PUP-3547   Re: File Server Mounts Should Support Directory Environments I just finished watching the PR triage recording on Youtube and reading through the notes; I can see where the confusion arose and it's probably due to the terse description I provided in the initial post. I've published an example of the r10k setup I use to the "production" branch of a Github repository and I'll use that repository and branch as a reference. In my current setup, I've manually configured a [files] mount point in fileserver.conf that maps to the path /etc/puppet/files. As mentioned before, I use this folder to distribute the various files that I can't generate or manipulate with Puppet: VMware Tools tarballs, installers/executables, etc. Most of the time, these files don't follow semantic versioning schemes or have no versioning scheme at all. Some of the sensitive files (like externally-supplied per-VM software licenses, keys tied to individual VMs, etc.) belong to individual VMs in specific environments and should not be accessible from other VMs or environments. Although the current file server can differentiate files for different VMs based on the certificate name (%H), the hostname (%h) or the domain name (%d), it has no knowledge of the environment in which the node was assigned to, even though that information must be supplied in the request. Therefore, in it's current state, all the files in the file server mount are shared among all environments. The first suggested workaround for that was to interpolate the $environment variable into the source URL; superficially, this will work as intended, but it cannot prevent a node from accessing files outside of it's environment which in turn breaks the isolation that r10k helps to enforce. The next alternative, as mentioned in the recording, would be to use "data" modules, which are basically only Puppet modules with a name and a version number stamped onto them. These modules would then be managed by r10k. This only shifts the problem somewhere else however: now I must manage a combinatorial explosion of Puppet modules, their versions, and their respective Git repositories and what relationships they have with individual VMs. The solution I'd landed on was to use a file server mount, but have it located within the directory environment I'd deployed with r10k: $ find /etc/puppet/environments -type d -name 'files' /etc/puppet/environments/development/files /etc/puppet/environments/staging/files /etc/puppet/environments/production/files With a file server mount like the following (in fileserver.conf): [files] path /etc/puppet/environments/%e/files allow * With my ENC assigning agents to specific environments, I could then transparently use different files from the file server mount without needing to encode environment-related logic within the manifests. For example: file { '/opt/vendor/conf/license.bin': # Retrieves "/etc/puppet/environments/$environment/files/vendor/license.bin". source => "puppet:///files/vendor/license.bin", owner => 'root', owner => 'root', mode => '0600' } Does this help clarify the original intention of this request? Add Comment   This message was sent by Atlassian JIRA (v6.3.7#6337-sha1:2ed701e) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.