Settings¶

The configuration for Smart-Proxy is held in the /etc/foreman-proxy/settings.yml or config/settings.yml file.

YAML start¶

The first non-comment line of this file must be three dashes.

---

SSL configuration¶

The existence of all the three ssl key entries below enables the use of an SSL connections.

NOTE that both client certificates need to be signed by the same CA, which must be in the ssl_ca_file, in order for this to work
see SSL for more information

:ssl_certificate: ssl/certs/fqdn.pem
:ssl_ca_file: ssl/certs/ca.pem
:ssl_private_key: ssl/private_keys/fqdn.key

This is the list of hosts from which the smart proxy will accept connections. If this list is empty then every verified SSL connection is allowed to access the API.

:trusted_hosts:
- foreman.prod.domain
- foreman.dev.domain

Instance attributes¶

If this entry is present and not false then Smart-Proxy will attempt to disconnect itself from the controlling terminal and daemonize itself.

:daemon: true

The port listened to by the proxy. If this is not present then the default Sinatra port of 4567 is used.

:port: 8443

TFTP section¶

Activate the TFTP management module within the Smart-Proxy instance.

The tftproot value is directory into which tftp files are copied and then served from. The tftp daemon will also be expected to chroot to this location. This component is only supported in the Unix environment

:tftp: true
:tftproot: /var/lib/tftpboot
:tftp_servername: name of your tftp server (used for next server value in your dhcp reservation) - defaults to the host name of your proxy.

NOTE: the foreman proxy user must have read/write access to the tftpboot/pxelinux.cfg and tftpboot/boot directories.

DNS section¶

Activate the DNS management module within the Smart-Proxy instance.

The DNS module can manipulate any DNS server that complies with the ISC Dynamic DNS Update standard and can therefore be used to manage both Microsoft and Bind servers.

The dns_key is used to validate the client request. If it is not present then the update operation is performed without peer verification, (not recommended.)
The dns_server option is used if the Smart-Proxy is not located on the same physical host as the DNS server. If it is not specified then localhost is presumed.

:dns: true
:dns_key: /home/proxy/keys/Kapi.+157+47848.private
:dns_server: dnsserver.site.domain.com

NOTE: if you use a key, make sure that the foreman proxy account can read that file.

DHCP section¶

Activate the DHCP management module within the Smart-Proxy instance.

:dhcp: true

If the DHCP server is ISC compliant then set dhcp_vendor to isc. In this case Smart-Proxy must run on the same host as the DHCP server.
If the proxy is managing a Microsoft DHCP server then set dhcp_vendor to native_ms. Smart-Proxy must then be run on an NT server so as to access the Microsoft native tools, though it does not have to be the same machine as the DHCP server. More details can be found at Foreman Architecture.

:dhcp_vendor: isc

The DHCP component needs access to the DHCP configuration file as well as the currently allocated leases. The section below shows these values for a RedHat client. In the case of a Smart-Proxy hosted on an Ubuntu machine then these values would be more appropriate: /etc/dhcp3/dhcpd.conf and /var/lib/dhcp3/dhcpd.leases

:dhcp_config: etc/dhcpd.conf
:dhcp_leases: etc/dhcpd.leases

NOTE: Make sure that the foreman proxy account can read both ISC configuration files.

If your native_ms implementation is slow then you can request that the smart proxy only operate on a subset of the subnets managed by the dhcp server.

:dhcp_subnets: [192.168.1.0/255.255.255.0, 192.168.11.0/255.255.255.0]

If you secured your DHCP with an "omapi_key", add the entries:

:dhcp_key_name: omapi_key
:dhcp_key_secret: XXXXXXXX

Puppet Certificate Authority section¶

Activate the Puppet CA management module within the Smart-Proxy instance.

This should only be enabled in the Smart-Proxy that is hosted on the machine responsible for providing certificates to your puppet clients. You would expect to see a directory /var/lib/puppet/ssl/ca on such a host.

:puppetca: true

If your puppet SSL directory is located elsewhere, you'll need to set 'ssldir' as well.

:ssldir: /etc/puppet/ssl

:puppetdir: /etc/puppet

The proxy requires write access to the puppet autosign.conf file, which is usually owner and group puppet, and has mode 0644 according to the puppet defaults.

Ensure the foreman-proxy user is added to the puppet group ( e.g. `gpasswd -a foreman-proxy puppet` or `usermod -aG puppet foreman-proxy`)

puppet.conf:

[master]
autosign = $confdir/autosign.conf {owner = service, group = service, mode = 664 }

Sudo access to the proxy is required - in your sudoers file ensure you have the following lines:

For older puppet (pre-3.0) with separate sub-commands available:

foreman-proxy ALL = NOPASSWD: /usr/sbin/puppetca *
Defaults:foreman-proxy !requiretty

For newer monolithic puppet without separate commands (3.0-onwards)

foreman-proxy ALL = NOPASSWD: /usr/bin/puppet cert *
Defaults:foreman-proxy !requiretty

Puppet section¶

Activate the puppet management module within the Smart-Proxy instance.

This should only be enabled in the Smart-Proxy that is hosted on the machine capable of executing puppetrun. This will be a puppetmaster.
This can also be set to true if you need to import puppet classes from the puppetmaster. Without this the import will not be possible

:puppet: true

:puppet_conf: /etc/puppet/puppet.conf
# Defaults to %25INSTALL_DIR%25/.puppet/puppet.conf

Sudo access to the proxy is required - in your sudoers file ensure you have the following lines:

Defaults:foreman-proxy !requiretty
foreman-proxy ALL = NOPASSWD: /usr/bin/puppetrun

If running puppet version 2.6+ you will need to use the following (use /opt/puppet/bin/puppet for Puppet Enterprise)

Defaults:foreman-proxy !requiretty
foreman-proxy ALL = NOPASSWD: /usr/bin/puppet

EDIT In my case the account which was triggering puppetrun was not foreman-proxy but foreman itself. It took me some time to figure out why puppetruns are not triggered.

Logging¶

The proxy's output is captured to the the log_file and may be filtered via the usual unix syslog levels:

• WARN
• DEBUG
• ERROR
• FATAL
• INFO
• UNKNOWN

See Ruby's Logger class for details.

:log_file: /tmp/proxy.log
:log_level: DEBUG