I was testing installation of foreman-proxy using another foreman server as ENC and also using the modules theforeman/puppet-apache, theforeman/puppet-puppet and theforeman/puppet-passenger

If I assigned the class foreman_proxy to this new host I would get the error:

Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Could not find template '' at /etc/puppet/environments/foreman/modules/puppet/manifests/config.pp:8 on node

and on the master would be:

(Scope(Class[Puppet::Config])) Could not look up qualified variable 'puppet::dir'; class puppet has not been evaluated

and

(Scope(Class[Puppet::Config])) Could not look up qualified variable 'puppet::agent_template'; class puppet has not been evaluated

This appears to be a result of foreman_proxy calling out directly to puppet::server::config
in manifests/config.pp

This wasn't an issue on the foreman server as I had an explicit node config and chained from puppet -> puppet::master -> foreman -> foreman_proxy but this is not something you can do with an ENC.

In the template file dns.yml.erb in any cases the dns_key configuration is set.

For any non production environments, a user may want to use a non secure DNS proxy communication, therefore the dns_key should be removable from the configuration.

I think it's better to set most booleans to false when you look at CA, Puppet, etc.

De default parameters are far from ideal to start with that I think it's better to set them all to false in params.pp.

Error: Could not set 'present' on ensure: ApipieBindings::MissingArgumentsError at 12:/etc/puppet/environments/production/modules/fo
reman_proxy/manifests/register.pp
Error: Could not set 'present' on ensure: ApipieBindings::MissingArgumentsError at 12:/etc/puppet/environments/production/modules/fo
reman_proxy/manifests/register.pp
Wrapped exception:
ApipieBindings::MissingArgumentsError
Error: /Stage[main]/Foreman_proxy::Register/Foreman_smartproxy[MASTERBOX]/ensure: change from absent to present failed
: Could not set 'present' on ensure: ApipieBindings::MissingArgumentsError at 12:/etc/puppet/environments/production/modules/foreman
_proxy/manifests/register.pp

Its weird I have the same version in another box, and its fine, I just deployed this, and it gives this error.

Using version 4 of this module on Debian Jessie with Foreman Proxy 1.12, the remote_execution::ssh plugin tries to install the package ruby-smart-proxy-remote-execution-ssh-core, but it is not available in the 1.12 repositories.

I'm not sure where to put this ...

Without sudo, the error is cryptic ;-)

10.0.0.4 - - [24/Oct/2014 13:29:00] "GET /puppet/ca HTTP/1.1" 406 60 0.0015
E, [2014-10-24T13:38:30.848300 #22585] ERROR -- : Failed to list certificates: can't convert false into String

Using version 4 of this module on Debian Jessie with Foreman Proxy 1.12, the remote_execution::ssh plugin tries to notify the smart_proxy_dynflow_core service, which is no in the catalog. Looking at the code tells me, that it's only defined on redhat based systems.

Hi,

when trying to install Foreman 1.6.3 and 1.7.rc1 on Debian Wheezy today, both installs failed for me with the following lines in the log:

E, [2014-11-24T11:19:44.856547 #4321] ERROR -- : 422 Unprocessable Entity
{
    "error" => {
                   "id" => nil,
               "errors" => {
            "base" => [
                [0] "Unable to communicate with the proxy: ERF12-2530 [ProxyAPI::ProxyException]: Unable to detect features ([RestClient::Forbidden]: 403 Forbidden) for proxy https://foreman.moll.credativ.lan:8443/features",
                [1] "Please check the proxy is configured and running on the host."
            ]
        },
        "full_messages" => [
            [0] "Unable to communicate with the proxy: ERF12-2530 [ProxyAPI::ProxyException]: Unable to detect features ([RestClient::Forbidden]: 403 Forbidden) for proxy https://foreman.moll.credativ.lan:8443/features",
            [1] "Please check the proxy is configured and running on the host."
        ]
    }
}
Could not set 'present' on ensure: 422 Unprocessable Entity at 12:/usr/share/foreman-installer/modules/foreman_proxy/manifests/register.pp

After debugging with @PsycoHenny, we noticed that adding localhost to trusted_hosts solves the issue.

Thus, the following diff would fix the issue:

diff --git a/manifests/params.pp b/manifests/params.pp
index 2d37666..cf4ce56 100644
--- a/manifests/params.pp
+++ b/manifests/params.pp
@@ -29,7 +29,7 @@ class foreman_proxy::params {
   $ssl_key = "${puppet_home}/ssl/private_keys/${::fqdn}.pem"

   # Only hosts listed will be permitted, empty array to disable authorization
-  $trusted_hosts = [$::fqdn]
+  $trusted_hosts = [$::fqdn, localhost]

   # Whether to manage File['/etc/sudoers.d'] or not.  When reusing this module,
   # this may be disabled to let a dedicated sudo module manage it instead.

Yet we are unsure why exactly this happens, $::fqdn is set properly.

For reference, /etc/hosts of the machine in question looks like this:

127.0.0.1   localhost
127.0.1.1   foreman.moll.credativ.lan   foreman

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

On a fresh install using stable to configure a standalone proxy, we fail right away with multiple errors since the settings.d subdir does not exist after package install.

Error: Could not set 'file' on ensure: cannot generate tempfile `/etc/foreman-proxy/settings.d/puppet.yml20140819-12606-miaae4-9' at 30:/etc/puppet/environments/production/modules/foreman_proxy/manifests/settings_file.pp

SSIA

When I manage my DHCP pools from the foreman-dhcp module and also manage for foreman proxy with dhcp enabled I get:

Error: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Evaluation Error: Error while evaluating a Resource Statement, Evaluation Error: Error while evaluating a Resource Statement, Duplicate declaration: Class[Dhcp] is already declared; cannot redeclare at /etc/puppetlabs/code/environments/common/foreman_proxy/manifests/proxydhcp.pp:27 at /etc/puppetlabs/code/environments/common/foreman_proxy/manifests/proxydhcp.pp:27:3 on node

What am I doing wrong here ?

Thanks!

This was needed for EL6 but it's included in EL7 so we can drop it. It would be a major version bump so I'm leaving this open for the next release.

It looks like the latest version changed $puppet_home from $puppet::params::server_vardir to $puppet::params::vardir. The problem is $puppet::params::vardir doesn't exist in the theforeman/puppet module.

I'm having an issue with the setup using this module for DHCP.

When I add a host I get the message "Subnet not found". As this module doesn't add the subnets to the dhcpd.conf, what should be set then ?

Or do I need some other settings on the subnets in Foreman ?

As this is, in the Foreman docs and this module documentation is unclear, what does dhcp_managed actually do ? It grabs the IP/subnet for the DHCP host from facter but that subnet is only usable for starting dhcpd and some hosts in that same subnet, what about the other subnets you want to have in Foreman ?

If we need dhcp_managed on false and configure it on the ::dhcp module itself is it not better to have a pools class in this module as well ?

Please explain as PXE-boot needs dhcp for the host to provision at least and this module makes it unclear on that part.

The metadata.json dependency for extlib is out of date, causing conflicts with other modules.

 {
     "name": "puppet/extlib",
     "version_requirement": ">= 0.10.4 < 1.0.0"
 }

In almost all plugin templates there is this line:
:enabled: <%= @module_enabled %>

Shouldn't that be something like:
:enabled: <%= scope.lookupvar('::foreman_proxy::plugin::name::enabled') %>
?

$puppet_etcdir is hardcoded to '/etc/puppet', which breaks under Puppet 4.

The comments in the puppet.yml config template listing puppet_proxy_puppetssh are incorrect, it should be puppet_proxy_ssh (see http://projects.theforeman.org/issues/15323).

I think for compatibility we should also munge a value of puppetssh to ssh in the $puppet_provider parameter, as the config file migration in Smart Proxy 1.12 also changes it. Perhaps also issue a deprecation warning for the old name?

I have the lastest branch of puppet-foreman, and puppet-foreman_proxy in my puppet modules directory. When I assign foreman_proxy to a host running Scientific Linux 6.3, it goes through the install and gives the following:

info: create new repo foreman_proxy in file /etc/yum.repos.d/foreman_proxy.repo
notice: /Stage[main]/Foreman_proxy::Install/Foreman::Install::Repos[foreman_proxy]/Yumrepo[foreman_proxy]/descr: descr changed '' to 'Foreman stable repository'
notice: /Stage[main]/Foreman_proxy::Install/Foreman::Install::Repos[foreman_proxy]/Yumrepo[foreman_proxy]/enabled: enabled changed '' to '1'
notice: /Stage[main]/Foreman_proxy::Install/Foreman::Install::Repos[foreman_proxy]/Yumrepo[foreman_proxy]/gpgcheck: gpgcheck changed '' to '0'
info: changing mode of /etc/yum.repos.d/foreman_proxy.repo from 600 to 644
err: /Stage[main]/Foreman_proxy::Install/Package[foreman-proxy]/ensure: change from absent to present failed: Execution of '/usr/bin/yum -d 0 -e 0 -y install foreman-proxy' returned 1: Error: Cannot retrieve repository metadata (repomd.xml) for repository: foreman_proxy. Please verify its path and try again

notice: /Stage[main]/Foreman_proxy::Config/User[foreman-proxy]: Dependency Package[foreman-proxy] has failures: true

When I check /etc/yum.repos.d/foreman_proxy.repo the contents are:

[foreman_proxy]
name=Foreman stable repository
enabled=1
gpgcheck=0

The output of facter | grep operating is

operatingsystem => Scientific
operatingsystemrelease => 6.3

On puppet-foreman params.pp is

OS specific paths

case $::operatingsystem {
redhat,centos,fedora,Scientific: {
$puppet_basedir = '/usr/lib/ruby/site_ruby/1.8/puppet'
$apache_conf_dir = '/etc/httpd/conf.d'
$yumrepo = $operatingsystemrelease ? {
16 => 'http://yum.theforeman.org/releases/1.0/f16/$basearch',
17 => 'http://yum.theforeman.org/releases/1.0/f17/$basearch',
/(5.)/ => 'http://yum.theforeman.org/releases/1.0/el5/$basearch',
/(6.)/ => 'http://yum.theforeman.org/releases/1.0/el6/$basearch'
}
}

So it seems like it should work, but it never finds the $yumrepo variable.

So trying to install/setup the proxy for puppet functionality on my compile masters (so, no puppetca, also no puppetrun functionality), this module is insisting on setting up sudo. I'd like an option to turn that off completely (i can work up a PR for that), but also as is, since I hadn't defined a foreman_proxy::puppetrun_provider, it was undef, which seems to lead to creating a sudoers.d entry with * for the command which is invalid (and even if it was valid, would be scary). So, then sudoers doesn't parse and breaks.

my "fix" was, even though I'm not using puppetrun, setting the provider and a command so the template has something to fill in there and append the * as it expects.

On CentOS 6 the module is looking for grub.efi at/boot/efi/EFI/centos/grub.efi when it should be looking for /boot/efi/EFI/redhat/grub.efi.

It seems that the user/usergroup is not created anymore when using the PC1 repo from puppetlabs and package 4.9.4

Foreman_proxy gives the following error:

err Puppet Could not set groups on user[foreman-proxy]: Execution of '/usr/sbin/usermod -G puppet foreman-proxy' returned 6: usermod: group 'puppet' does not exist
err /Stage[main]/Foreman_proxy::Config/User[foreman-proxy]/groups change from to puppet failed: Could not set groups on user[foreman-proxy]: Execution of '/usr/sbin/usermod -G puppet foreman-proxy' returned 6: usermod: group 'puppet' does not exist

How can we fix this the best way ?

Please consider adding option to manage trusted_puppetmaster_hosts parameter

I don't have much to go on other then log entries that look like this:

Apr 27 10:32:08 cfg01 puppet-agent[15348]: (/Stage[main]/Foreman_proxy::Register/Foreman_smartproxy[cfg01.phx.dealnews.net]) Could not evaluate: Proxy cfg01.phx.dealnews.net cannot be registered ("\xE2" on US-ASCII): N/A

Currently, parameters to service resource are hardcoded. I want to run foreman-proxy under passenger, so I need service foreman-proxy to be stopped. Solution would be to add service_ensure and service_enable parameters.

Current workaround is to amend service parameters by:

Service <| title == 'foreman-proxy' |> {
        ensure  => stopped,
        enable  => false,
}

This line causes foreman_proxy::groups to always include the puppet group, regardless of whether foreman_proxy::puppet is true or false. This breaks things:

Error: Could not set groups on user[foreman-proxy]: Execution of '/sbin/usermod -G puppet foreman-proxy' returned 6: usermod: group 'puppet' does not exist

Hello, I've got this in my node definition
class {"foreman_proxy":
puppetca => false,
manage_sudoersd => true,
puppetrun => false,
tftp => true,
tftp_servername => $ipaddress_eth0,
dhcp => true,
dhcp_managed => true,
dhcp_interface => 'eth0',
dhcp_gateway => '10.3.3.254',
dhcp_range => "10.3.3.50 10.3.3.250" ,
dns => false,
dns_managed => false,
}

And every time I run puppet agent it kills my master
puppet agent:
puppetlabs-release-6-10.noarch
puppet-3.6.2-1.el6.noarch

puppetmaster:
puppetlabs-release-6-10.noarch
puppet-server-3.6.2-1.el6.noarch

To reproduce this issue one can use Vagrant file in https://github.com/kostyrevaa/foreman

Despite setting parameter 'tftp_manage' to false, the module still insists on including ::tftp::params.
This should not happen and can presumably be fixed easily by these modifications:

In params.pp: don't include ::tftp::params
In tftp:pp: lazily evaluate variable 'tftp_root':
if ($foreman_proxy::tftp_root == undef) {
initialize from tftp::params
} else {
use main parameter value
}

Hello, foreman-proxy 1.8 introduced caching of Puppet manifests on the proxy. I use this module to manage settings.d/puppet.yml and would like to be able to enable manifest caching. Is this a planned feature or is it already in v 2.2.2 (or master)?

Thank you

What do you feel about adding a new parameter to plugins in order to manage updates/versions? The same thing as in init class: $version, but for each plugin? If I send a pull request it will be ok?

As we need the puppet-agent-oauth package we also need the foreman.repo which is not added by default.

I've just been playing with setting up a RaspberryPi based Foreman appliance, and hit a minor snag. In the TFTP class we hardcode the amd64 versions of the EFI Grub packages - this doesn't exist for ARM boards. There is an equivalent ARM package though.

What's the best solution here? Parameterise the EFI packages? Or maybe just add an $manage_efi flag and surround the whole EFI block with it?

Currently the permissions for "${puppet::server_ssl_dir}/private_keys/${::fqdn}.pem" are only set when configuring puppet master thru Foreman. The "puppet" group has no read/write access to this file.

What should happen is that the following block taken from /usr/share/foreman-installer/modules/puppet/manifests/server/config.pp

file { "${puppet::server_ssl_dir}/private_keys/${::fqdn}.pem":
group => $puppet::server_group,
mode => '0640',
}

Needs to be removed with file modules/foreman_proxy/manifests/config.pp amended with following patch:

--- config.pp.orig 2013-12-19 10:48:21.548964233 +0000
+++ config.pp 2013-12-19 10:42:43.899965498 +0000
@@ -7,6 +7,14 @@
Class['puppet::server::config'] -> Class['foreman_proxy::config']
}

• if $foreman_proxy::ssl and !defined(Class['puppet::server::config']) {
• file { $foreman_proxy::ssl_key:

•  group => $puppet::server_group,
  

•  mode  => '0640',
  

• }
• }

if $foreman_proxy::puppetca { include foreman_proxy::puppetca }
if $foreman_proxy::tftp { include foreman_proxy::tftp }

As per #307 (comment), it probably makes sense to set this for all OSs.

Could not retrieve catalog from remote server: Error 400 on SERVER: Usage: cache_data(name, initial_data) at /etc/puppet/environments/production/modules/foreman_proxy/manifests/params.pp:253 on node www.example.com

Discovered when building a TFTP only server (no puppet proxy or any other proxies) on EL7.

Prior to puppet 4 (AIO packaging), the 'puppet' package created a puppet user and group. This now only happens if the puppetserver package is installed.

I ended up with this failure...

Error: Could not set groups on user[foreman-proxy]: Execution of '/sbin/usermod -G puppet foreman-proxy' returned 6: usermod: group 'puppet' does not exist
Error: /Stage[main]/Foreman_proxy::Config/User[foreman-proxy]/groups: change from  to puppet failed: Could not set groups on user[foreman-proxy]: Execution of '/sbin/usermod -G puppet foreman-proxy' returned 6: usermod: group 'puppet' does not exist

I can easily enough workaround this by creating the group in my profile, but I guess it should probably be fixed in the module?

If someone overwrites the variable $ssl_port and not $registered_proxy_url, the variable $registered_proxy_url will always have port 8443 because it will be created before foreman_proxy class is initialized:

• first params class is initialized (due to inheritance) with default values
• in main class any default parameters will take the above default values, even if some of the variables used will be overwritten

In order to fix this, maybe it will be better to not parametrize $registered_proxy_url and construct it in init class instead. I don't see any reason why someone will overwrite registered_proxy_url variable.

The same should be true for:

• $template_url, which uses default http_port
• $tftp_dirs which uses default tftp_root
• $dns_tsig_principal which uses default dns_realm

ruby-foreman-api is available only in nightly deb repo so puppet-foreman_proxy master does not work with "register_in_foreman => true" (default value) with stable repository

I think it would be saner to use the default gateway instead of eth0. Currently I'm using those facts to set the default interface to an existing value:

https://github.com/kwilczynski/facter-facts/blob/master/default_gateway.rb

Maybe they could be added to foreman and default the interface to $::default_gateway_interface?

Params to control the following puppetca settings are missing:
puppetca_use_sudo
sudo_command

Furthermore, the sudo rule to allow foreman-proxy to run 'puppet cert' is set to run as root, should it not run as the 'puppet' user instead? There is no need to run as root, and if you have your puppetcerts on NFS running the 'puppet cert' command as root will not work (unless you use 'no_root_squash' which you really shouldnt).

I can provide a PR for this, just wanted to check first if it would be accepted...

When I set dhcp = true, and then run puppet agent --test, I get the following error:

err: Could not retrieve catalog from remote server: Error 400 on SERVER: Puppet::Parser::AST::Resource failed with error ArgumentError: Could not find declared class dhcp at /etc/puppet/modules/development/foreman_proxy/manifests/proxydhcp.pp:23 on node

But when I leave it as the default dhcp false, everything appears to install fine.

Does enabling dhcp require me to set additional parameters?

Thanks!

Smart Proxy 1.10 will ship separate configuration files for DNS providers, instead of one large dns.yml. The templates in this module will need splitting up.

See https://github.com/theforeman/smart-proxy/tree/d905c67c/config/settings.d for example.

puppet_cache_location was removed in 1.9.0 via http://projects.theforeman.org/issues/11229, the parameter is obsolete and can be removed too.

from https://github.com/theforeman/smart_proxy_dns_powerdns/blob/master/README.md

To use MySQL, set the following parameters:

:powerdns_backend: 'mysql'
:powerdns_mysql_hostname: 'localhost'
:powerdns_mysql_username: 'powerdns'
:powerdns_mysql_password: ''
:powerdns_mysql_database: 'powerdns'

So the template is missing :powerdns_backend: 'mysql'. The powerdns plugin also added multiple backend support which would also need to be addressed at some point.

Looks like the registration provider was updated to have an ssl_ca parameter that doesn't seem to exist?

I'm using the latest version of the foreman module and foreman_proxy modules:

Error: Could not retrieve catalog from remote server: Error 400 on SERVER: no parameter named 'ssl_ca' at /etc/puppetlabs/code/environments/foreman_proxy/vendor/foreman_proxy/manifests/register.pp:5 on Foreman_smartproxy[] at /etc/puppetlabs/code/environments/foreman_proxy/vendor/foreman_proxy/manifests/register.pp:5 on node
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run

Installation via puppet agent -tv fails with the following execution:

apt -q -y -o DPkg::Options::=--force-confold install puppet-agent-oauth

Running on Ubuntu 16.04 (Azure VM)

Error: Execution of '/usr/bin/apt-get -q -y -o DPkg::Options::=--force-confold install puppet-agent-oauth' returned 100: Reading package lists...
Building dependency tree...
Reading state information...
The following NEW packages will be installed:
  puppet-agent-oauth
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 43.6 kB of archives.
After this operation, 79.9 kB of additional disk space will be used.
Get:1 http://deb.theforeman.org plugins/stable amd64 puppet-agent-oauth all 0.5.1-2 [43.6 kB]
Err:1 http://deb.theforeman.org plugins/stable amd64 puppet-agent-oauth all 0.5.1-2
  Hash Sum mismatch
Fetched 43.6 kB in 0s (168 kB/s)
E: Failed to fetch http://deb.theforeman.org/pool/plugins/stable/p/puppet-agent-oauth/puppet-agent-oauth_0.5.1-2_all.deb  Hash Sum mismatch

E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?

Have tried this solution with no success

Thanks in advance

The first run of a fresh install machine with the foreman_proxy module seems to fail on a CentOS 7.3.1611 install. Second run goes well but fails again on the puppet user.

Is there some cache issue on the first run, IPv6 needs to be disabled to make it default work on any network ?

Execution of '/usr/bin/yum -d 0 -e 0 -y install foreman-proxy' returned 1: One of the configured repositories failed (Foreman stable),
and yum doesn't have enough cached data to continue. At this point the only
safe thing yum can do is fail. There are a few ways to work "fix" this:

1. Contact the upstream for the repository and get them to fix the problem.

2. Reconfigure the baseurl/etc. for the repository, to point to a working
   upstream. This is most often useful if you are using a newer
   distribution release than is supported by the repository (and the
   packages for the previous distribution release still work).

3. Run the command with the repository temporarily disabled
   yum --disablerepo=foreman_proxy ...

4. Disable the repository permanently, so yum won't use it by default. Yum
   will then just ignore the repository until you permanently enable it
   again or use --enablerepo for temporary usage:

yum-config-manager --disable foreman_proxy
or
subscription-manager repos --disable=foreman_proxy

5. Configure the failing repository to be skipped, if it is unavailable.
   Note that yum will try to contact the repo. when it runs most commands,
   so will have to try and fail each time (and thus. yum will be be much
   slower). If it is a very temporary problem though, this is often a nice
   compromise:

yum-config-manager --save --setopt=foreman_proxy.skip_if_unavailable=true

failure: repodata/repomd.xml from foreman_proxy: [Errno 256] No more mirrors to try.
http://yum.theforeman.org/releases/latest/el7/x86_64/repodata/repomd.xml: [Errno 14] curl#7 - "Failed to connect to 2001:4802:7802:103:be76:4eff:fe20:c55: Network is unreachable"
http://yum.theforeman.org/releases/latest/el7/x86_64/repodata/repomd.xml: [Errno 14] curl#7 - "Failed to connect to 2001:4802:7802:103:be76:4eff:fe20:c55: Network is unreachable"
http://yum.theforeman.org/releases/latest/el7/x86_64/repodata/repomd.xml: [Errno 14] curl#7 - "Failed to connect to 2001:4802:7802:103:be76:4eff:fe20:c55: Network is unreachable"
http://yum.theforeman.org/releases/latest/el7/x86_64/repodata/repomd.xml: [Errno 14] curl#7 - "Failed to connect to 2001:4802:7802:103:be76:4eff:fe20:c55: Network is unreachable"
http://yum.theforeman.org/releases/latest/el7/x86_64/repodata/repomd.xml: [Errno 14] curl#7 - "Failed to connect to 2001:4802:7802:103:be76:4eff:fe20:c55: Network is unreachable"
http://yum.theforeman.org/releases/latest/el7/x86_64/repodata/repomd.xml: [Errno 14] curl#7 - "Failed to connect to 2001:4802:7802:103:be76:4eff:fe20:c55: Network is unreachable"
http://yum.theforeman.org/releases/latest/el7/x86_64/repodata/repomd.xml: [Errno 14] curl#7 - "Failed to connect to 2001:4802:7802:103:be76:4eff:fe20:c55: Network is unreachable"
http://yum.theforeman.org/releases/latest/el7/x86_64/repodata/repomd.xml: [Errno 14] curl#7 - "Failed to connect to 2001:4802:7802:103:be76:4eff:fe20:c55: Network is unreachable"
http://yum.theforeman.org/releases/latest/el7/x86_64/repodata/repomd.xml: [Errno 14] curl#7 - "Failed to connect to 2001:4802:7802:103:be76:4eff:fe20:c55: Network is unreachable"
http://yum.theforeman.org/releases/latest/el7/x86_64/repodata/repomd.xml: [Errno 14] curl#7 - "Failed to connect to 2001:4802:7802:103:be76:4eff:fe20:c55: Network is unreachable"

`

In an environment where you don't want a monolithic foreman deployment (E.G using different modules for puppet and tftp) - it should still be possible to deploy foreman-proxy using Puppet.

I have a conflict with the saz/sudo module v4.2.0. which is also declaring File[/etc/sudoers.d].
Full error:
Error: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Evaluation Error: Error while evaluating a Resource Statement, Duplicate declaration: File[/etc/sudoers.d] is already declared in file /etc/puppetlabs/code/environments/development/modules/sudo/manifests/init.pp:147; cannot redeclare at /etc/puppetlabs/code/environments/development/modules/foreman_proxy/manifests/config.pp:119 at /etc/puppetlabs/code/environments/development/modules/foreman_proxy/manifests/config.pp:119:9 on node mycomputer

https://github.com/theforeman/puppet-foreman_proxy/blob/master/manifests/tftp.pp#L32

By managing the wget package unconditionally, foreman_proxy::tftp cannot be used in environments that already manage the wget package.