Issue #11994 has been updated by Dominic Cleal. Status changed from Unreviewed to Needs Decision
I think attempting to support this in Puppet at the moment would be incredibly difficult, particularly as support for chroots between providers and the tools they use varies by a huge amount. Last time it came up in #661, it was rejected. The closest thing that I can see Puppet supporting for now is a non-default installation root for a package, as the "root" parameter already exists to indicate the install root. The description could be changed to "read/write" and providers updated on a case-by-case basis. This clearly isn't great for a chroot though, as you'd have a single package database (e.g. rpm --prefix) rather than one per chroot (--dbpath). #7286 also covers this for the 'pip' provider. ---------------------------------------- Feature #11994: Package resource: chroot/jail path https://projects.puppetlabs.com/issues/11994 Author: Mike McLane Status: Needs Decision Priority: Normal Assignee: Category: Target version: Affected Puppet version: Keywords: chroot jail package linux path Branch: Puppet 2.7.9 CentOS 5.x / CentOS 6.x I currently have to create a custom type in order to provide support for installing packages into a chroot under Linux. I would like to have a custom property added to the packages resource type of "chroot" or "chrootpath", signifying the path to the install root for that package. All packages would normally default to "/" for the chroot property. Alternatively, if I could pass in a value to the provider type (such as, --installroot=xxx to a yum provider) -- that might also work. Why not just run puppetd inside of a chroot? We make all efforts to put the minimal amount of data into a chroot jail to limit exposure of any information that an attack could use. Running puppet inside the chroot would require some amount of metadata or configuration to exist inside the chroot, including but not limited the client cert .. the host/ip for the puppet master.. any bucketed cache files locally. Running puppet inside the chroot also requires a bit of a hack in that we either have to create a special chroot-only hostname for the chroot (configuration complexity) or duplicate the hostname of the parent node, thereby exposing the chroot to configuration bits that should not be applied (and creating some confusion from the server check-in side). It would also be nice to apply a chroot or jail property to other standard resource types -- such as users, crons, groups, etc... but the most important resource type for us to resolve is the package type. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" 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-bugs?hl=en.
