intrigeri <intrig...@debian.org> writes: > Let's assume one needs exported resources, and thus PuppetDB, but they > want to confine PuppetDB as much as possible, in order to avoid the > need to trust 3rd-party (upstream) APT repositories on the > puppetmaster. So, say PuppetDB is installed from upstream on a > dedicated system. Then, if I got it right, the only bit missing in > Debian, for the puppetmaster to be able to connect to PuppetDB without > using any 3rd-party packages, is puppetdb-termini. Correct so far?
That is correct. The puppetdb-termini package contains what the puppet master needs to connect to a puppetdb. > puppetdb-termini has no dependencies except puppet-agent. It just > ships 16 .rb files, that live in the upstream Puppet Git repository, > and are distributed in PuppetDB upstream tarballs. > > So it seems that the only realistic way to go, in order for Debian > Stretch to support the use case I've described, without having to > tackle the packaging of PuppetDB itself, would be to package > puppetdb-termini. Would you, or anyone else, be up to it? Yes. In theory (and documentation) the puppetdb-termini package must match the version of the puppetdb you are connecting to. In practice, the puppetdb-termini is updated less frequently than puppetdb, and it may work without updating, but without any promises. Debian only accepts one version of a package at a time. This may prevent you from upgrading puppetdb to a version not supported by the puppetdb-termini in Debian, and when the puppetdb-termini package in Debian is updated, you may have to update your PuppetDB installation to follow. Apart from that, it does not look very hard at all to build only the puppetdb-termini from the puppetdb source. -- Stig Sandbeck Mathisen <s...@debian.org>
