Puppet agent provisioning on non routed subnet

Hello,

I’m facing the following problem :

Hello,

I’m facing the following problem :

I’d like Puppet facts to be send from the hosts I provision to the Foreman server but they are on a private non-routed subnet, thus the puppetlabs repo is unreachable. So they don’t even have puppet rpms installed.

What would be the best way to bootstrap this ?

As a matter of fact, it is common practice for an HPC cluster to have its compute nodes on a private non routed subnet. And that this type of nodes I’d like to provision with Foreman.

Also, what am I supposed to set up in the UI to have client facts : do I have to set a puppet_enable parameter somewhere or is it automatically done in a standard (routed network) setup ?

Thanks


Thomas HUMMEL

Does your private subnet not have a NAT setup? In some HPC setups I’ve managed the NAT was a large whitelist of what outside the center could be reached from compute nodes which allowed things like Puppet repos to be accessed but not allowing the entire internet to be accessed from compute nodes.

You could also create a local mirror of Puppetlabs repos and have compute nodes access the local mirror.

  • Trey

That’s my usual solution as well - createrepo . should create a basic non-GPG’d repo out of a directory of RPMs.

Thanks for your answer

No.

Yes. That’s what I’m doing for other purposes (ex: newer version of rsyslog, …).

Next question then is how do I bootstrap puppet-agent install for an unattended host ? As a matter of fact, I need to state :

  • my custom repo
  • the package(s) to be installed
  • the puppet master (which is the Foreman server as I understand it)

what would be the best way to do it ? In the kickstart file or does foreman offer a better way to do it ?

Thanks


TH

Maybe I’m too specific. Forget about this specific and please consider this more generic one :

What is the best way to perform post install bootstrap tasks, like installing puppet agent or copying a ssh key to further provision (with ansible for instance) an unattended host built by foreman ? Should I look into kickstart only ?

Thanks.


TH

Depends strongly on what you’re building, but broadly speaking… if it’s PXE then yes, customizations to the kickstart/preseed templates are the way to go (that’s how we automate the Puppet certificates, for example). For image-based systems, cloud-init using the metadata service for whatever platform you’re building on is probably best.

Also note that Katello focuses on repository management. It uses pulp to manage repositories. That allows you to easily host repositories locally. I know there are also plenty of users who only use Pulp without Katello and that can also be an option.

Ok, thanks.

It works for Puppet but, it seems harder with foreman* : for instance, at the moment I try to install a proxy_only server (dhcp, dns, tftp) as I describe here.

But somehow foreman-release-1.17.1-1.el7.noarch gets installed and thus override my foreman*.repo holding the path to my local copies of the upstream repos.

I tried adding --enable-foreman to what I’m doing in the post cited above.
My exact command is :

# foreman-installer --enable-foreman  --no-enable-foreman-cli     --no-enable-foreman-plugin-bootdisk     --no-enable-foreman-plugin-setup  --enable-foreman-proxy     --foreman-proxy-dhcp=true     --foreman-proxy-dhcp-managed=true     --foreman-proxy-dhcp-interface=eth0     --foreman-proxy-dhcp-subnets="192.168.10.0/24"     --foreman-proxy-dhcp-gateway="192.168.10.10"     --foreman-proxy-dhcp-range="192.168.10.200 192.168.10.210"     --foreman-proxy-tftp=true     --foreman-proxy-tftp-managed=true     --foreman-proxy-dns=true     --foreman-proxy-dns-managed=true     --foreman-proxy-dns-interface=eth0     --foreman-proxy-dns-reverse=10.168.192.in-addr.arpa     --foreman-proxy-dns-forwarders="157.99.64.64"     --foreman-proxy-dns-forwarders="157.99.64.65"     --foreman-proxy-bmc=true     --foreman-proxy-foreman-base-url=https://foreman.dev.cluster.pasteur.fr     --foreman-proxy-trusted-hosts=foreman.dev.cluster.pasteur.fr 
  • the 2 oauth relative options

Thanks.


TH

If your hosts are CentOS 7 based and if your using Katello, do you think you can apply the process as if you were registering an already existing host ? Here is what I m doing for these hosts manually, but it s probably possible to use a dedicated user with only the required roles and give password through provisioning templates.

I have a katello setup with centos, katello client and puppetlabs repositories mirrored, and their activation keys. Katello provides a bootstrapping script which register the host, subscribes the host to the repositories defined in activation key, set the hostgroup, install puppet package and configure the environment from the hostgroup environment.

wget --no-check-certificate https://$FOREMANPROXY/pub/bootstrap.py
python bootstrap.py --server=$FOREMANPROXY
–login=admin --password=mysecurepassword --activationkey=“centos7,puppet-5,katello-client”
–organization=“MyOrg” --location=“MyLocation”
–deps-repository-url=“http://$FOREMANPROXY/pulp/repos/company/Library/custom/centos-7/centos7-os/
–hostgroup=“MyHostgroup” --skip migration --verbose

Had to fix puppet path in bootstrap.py because puppetlabs install it in /opt (and another hardcoded variable, I dont remember which) but it works well on Foreman/Katello server and could be solved cleanly with proper PATH environment variable at provisioning.

For use a smartproxy, setup it to sync the lifecycle environment which holds packages (I use Library/Default view to use always updated repositories). Then fix some Apache configuration and the bootstrap script will works (Bug #24341: on smartproxies, calls to api/v2/ are no passed to upstream foreman server - Katello - Foreman)

That’s a good point - @packaging do you have any advice on the interaction of release RPMs with custom repos?