Getting Started

Upon creating a new IPv6 subnet, i.e:

Name:            Test
Protocol:        IPv6
Network Address: 2001:db8::
Network Prefix:  64

no “DHCP Proxy” is being associated with that IPv6 subnet.

Any IPv4 created subnet happily reflects “foreman.domain.com” as the associated “DHCP Proxy” and works as expected.

On the host, /etc/dhcp/dhcpd6.conf is not configured and neither is the dhcpd6 service enabled nor started.

Yet I can’t find a “foreman-installer” option that would specifically enable IPv6 seperately from IPv4 …

Which begs the question: How does one go about getting the Smart Proxy to enable/manage dhcpd6?

Hosts were added manually, so far. Created them on VMware ESXi server. (CentOS 7 Minimal).
Then, installed puppet-agent on each host. Then ran “puppet agent --test”.
It complains: Exiting; no certificate found and waitforcert is disabled
Ignore that. Go to the Foreman UI: Infrastructure -> Smart Proxies
Select Edit Certificates, and then Sign …
Run puppet agent --test again on the host, and it is added.

In the interim I’m moving forward, eyes closed, just patting softly in front of me, hoping not too break to much as I stumble forward as follows:

  1. Created /etc/dhcp/dhcpd6.conf manually
  2. Started & enabled DHCP6 service
  3. Created IPv6 reverse lookup zone file manually
  4. Restarted BIND service

This resolved the error:

Create Reverse IPv6 DNS record for test-01.domain.com task failed with the following error: ERF12-2357 [ProxyAPI::ProxyException]: Unable to set DNS entry ([RestClient::BadRequest]: 400 Bad Request) for proxy https://foreman.domain.com:9090/dns

when trying to create a new HOST by specifying the MAC address and IPv6 subnet in the Interface config of the web interface.

Whilst fiddling with the config files manually, I also amended the DHCPv4 range, only to notice how the foreman-installer will set the DHCPv4 range back to the “initial range”, even though not even being referenced during the configuration re-run … :crossed_fingers: (Something to remember)

Yet still I couldn’t call it a week as the firewalld service had to be stopped before DHCPv6 would answer the client, even though all the ports are open. What CentOS sorcery is this?

iptables -L -v -n

0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22 ctstate NEW
0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:53 ctstate NEW
828 54465 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:53 ctstate NEW
1   352 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:67 ctstate NEW
0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:68 ctstate NEW
0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:69 ctstate NEW
0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:80 ctstate NEW
0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:443 ctstate NEW
0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:3000 ctstate NEW
0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:3306 ctstate NEW
0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpts:5910:5930 ctstate NEW
0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:5432 ctstate NEW
0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:8140 ctstate NEW
0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:8443 ctstate NEW

ip6tables -L -v -n

0     0 ACCEPT     tcp      *      *       ::/0                 ::/0                 tcp dpt:22 ctstate NEW
0     0 ACCEPT     udp      *      *       ::/0                 fe80::/64            udp dpt:546 ctstate NEW
0     0 ACCEPT     tcp      *      *       ::/0                 ::/0                 tcp dpt:53 ctstate NEW
0     0 ACCEPT     udp      *      *       ::/0                 ::/0                 udp dpt:53 ctstate NEW
0     0 ACCEPT     udp      *      *       ::/0                 ::/0                 udp dpt:67 ctstate NEW
0     0 ACCEPT     udp      *      *       ::/0                 ::/0                 udp dpt:68 ctstate NEW
0     0 ACCEPT     udp      *      *       ::/0                 ::/0                 udp dpt:69 ctstate NEW
0     0 ACCEPT     tcp      *      *       ::/0                 ::/0                 tcp dpt:80 ctstate NEW
0     0 ACCEPT     tcp      *      *       ::/0                 ::/0                 tcp dpt:443 ctstate NEW
0     0 ACCEPT     tcp      *      *       ::/0                 ::/0                 tcp dpt:3000 ctstate NEW
0     0 ACCEPT     tcp      *      *       ::/0                 ::/0                 tcp dpt:3306 ctstate NEW
0     0 ACCEPT     tcp      *      *       ::/0                 ::/0                 tcp dpts:5910:5930 ctstate NEW
0     0 ACCEPT     tcp      *      *       ::/0                 ::/0                 tcp dpt:5432 ctstate NEW
0     0 ACCEPT     tcp      *      *       ::/0                 ::/0                 tcp dpt:8140 ctstate NEW
0     0 ACCEPT     tcp      *      *       ::/0                 ::/0                 tcp dpt:8443 ctstate NEW

and then …

… also noticed that the provision template expanded incompletely:

http://ftp.debian.org/debian/dists//main/installer-amd64/current/images/netboot/debian-installer/amd64/linux
                                  ^ 
                  expecting a "debian9.7" here

It’s three months later … and I’m still battling to auto-provision the first host. :tired_face:

I’m actually not sure where the status of our IPv6 stack is, I recall was taking a while to get all the moving pieces in place - @TimoGoebel do you know?

We know how long the installer commands get, so the installer remembers all previous options given to it. Thus just foreman-installer will produce the same result as last time. If you want to change options, then yes, you have to specify them. Always, -n is your friend to allow you to see what would be changed.

1 Like

Couldn’t sleep and then snapped it.

Hosts > Operating Systems > Select defined OS

On “Operating Systems” tab, ensure “Release Name” is populated correctly, i.e. “debian9.7” allowing template’s URL to expand correct. :star_struck:

Now just the firewalld blocking only IPv6 traffic although the ports is configured to be allowed through.

Hopefully I can sleep now…

However, it needs to be “Debian9.7” (case sensitive) to resolve correctly and Foreman will ONLY register “debian9.7” regardless on how it’s typed or even when re-configured from scratch.

Does not resolve correctly in browser:
http://ftp.debian.org/debian/dists/debian9.7/main/installer-amd64/current/images/netboot/debian-installer/amd64/linux

Resolves correctly in browser:
http://ftp.debian.org/debian/dists/Debian9.7/main/installer-amd64/current/images/netboot/debian-installer/amd64/linux

dhcpd6 service also needs to be started before the dhcpd service to prevent:

Unable to save * Create Reverse IPv6 DNS record for test.domain.com task failed with the following error: ERF12-2357 [ProxyAPI::ProxyException]: Unable to set DNS entry ([RestClient::BadRequest]: 400 Bad Request) for proxy https://foreman.domain.com:9090/dns

Possibly relates to how OMAPI binds to the interface … ? (especially in dual stack scenarios)

Regardless, no “iPXE chain UEFI booting” goodness just yet :disappointed_relieved:

Is the following achievable with Foreman:

  1. Client creates IPv6 address via SLAAC
  2. RADV provides DHCPv6 address
  3. DHCPv6 provides bootfile URL via HTTP(S) … or TFTP
  4. Client downloads bootfile (iPXE)
  5. DHCPv6 provides image URL via HTTP(S)
  6. Client boots image
  • No IPv4 (At provisioning stage at least. Will be added for legacy support after provisioning has completed)
  • No TFTP server to manage (HTTP transfer being especially faster and more secured with HTTPS)

Is this possible or am I shooting at stars ?

However, if the latest hardware supported UEFI HTTP Boot, then even the DHCPv6 server could be discarded… Which has me continuously ponder why the industry is intentionally crippling UEFI HTTP Boot rather than embracing it for the ease it bring to the table ?

Me again. More progress… 3 steps forward, 2 back.
I now have one organization, two environments, three locations, two operating systems, and a hostgroup.

I’ve begun playing with OpenSCAP. Have SCAP Contents, created a Policy, a schedule, and assigned the
locations, organization, and host group. The foreman_scap_client class has been imported. So far, so good.

But when I tried to Run OpenSCAP scan manually, I got:
1: Error initializing command: Net::SSH::AuthenticationFailed - Authentication failed for user root@example.com
2: Exit status: EXCEPTION

Running puppet agent -t on the client, I see:
Error: Execution of ‘/bin/yum -d 0 -e 0 -y install rubygem-foreman_scap_client’ returned 1: Error: Nothing to do
Error: /Stage[main]/Foreman_scap_client/Package[rubygem-foreman_scap_client]/ensure: change from ‘purged’ to ‘present’ failed: Execution of ‘/bin/yum -d 0 -e 0 -y install rubygem-foreman_scap_client’ returned 1: Error: Nothing to do
Notice: /Stage[main]/Foreman_scap_client/File[foreman_scap_client]: Dependency Package[rubygem-foreman_scap_client] has failures: true
Warning: /Stage[main]/Foreman_scap_client/File[foreman_scap_client]: Skipping because of failed dependencies

Is this because the client lacks the appropriate repo?

Question for the community …
Are you still interested in my experiences here in “Getting Started”,
or am I at a point where this thread is so long and twisted that I might get better traction
by starting a new thread for each new question/issue?

Yes, you can get the foreman_scap_client form the plugins repo.

Smart proxy does only handle AAAA records for DNS, DHCP requests with IPv6 will error out.

Unfortunately no, Foreman is unable to manage IPv6 DHCP, at least ISC DHCP module cannot do that because ISC DHCP server omapi does not support that at all. This is from 2017:

At this point in time, we do not have plans to extend OMAPI to support DHCPv6. ISC DHCP is our legacy product and our primary development efforts are focused on it’s successor, Kea.

Kea provides a REST API for issuing commands in JSON text. This API is growing with each release and will offer a much richer set of abilities. The current release of Kea, 1.2.0, added a control agent which provides an HTTP interface for issuing commands to and getting responses from Kea servers. It also added commands to support host reservation management.

https://www.isc.org/kea-1-2/

Our next release, 1.3 adds commands to support lease and subnet management.

For the record, we are tracking this RFE in Feature #17615: Introduce KEA DHCP provider for smart-proxy - Smart Proxy - Foreman

Well, my take on this is that UEFI HTTP Boot is pretty “recent” technology, there are many boards out there without supporting it. That could be the reason, enterprise move slower.

1 Like

Thanks, Ondrej. I must be missing something here.
I thought the puppet-foreman_scap_client would be installed automatically.
I only found one reference that provided a hint:
2.3 Installing puppet-foreman_scap_client

“This repository is needed to install foreman_scap_client , witch [sic] will fail otherwise.”

So, I added foreman-plugins.repo to /etc/yum.repos.d on a client host.
But I am a little confused as to what to do next:

What is the difference between:
puppet module install theforeman-foreman_scap_client

and:
yum install puppet-foreman_scap_client

More research, and much trial and error later, I now have foreman_scap_client on all my Centos7 hosts.
But now it appears that I have a certificate configuration issue.

When run from the client, I get:
[root@web1 ~]# foreman_scap_client 1
File /var/lib/openscap/content/3e1654fd14a5352d65294db555710bfda5cad1a942209e2d787ea7940035616e.xml is missing. Downloading it from proxy.
Download SCAP content xml from: https://foreman.mydomain.com:9090/compliance/policies/1/content/3e1654fd14a5352d65294db555710bfda5cad1a942209e2d787ea7940035616e
SCAP content is missing and download failed with error: SSL_connect returned=1 errno=0 state=error: certificate verify failed
[root@web1 ~]#

When I Run OpenSCAP scan from the UI, I get:
1: rex login:
2: File /var/lib/openscap/content/3e1654fd14a5352d65294db555710bfda5cad1a942209e2d787ea7940035616e.xml is missing. Downloading it from proxy.
3: Download SCAP content xml from: https://foreman.mydomain.com:9090/compliance/policies/1/content/3e1654fd14a5352d65294db555710bfda5cad1a942209e2d787ea7940035616e
4: SCAP content is missing and download failed with error: SSL_connect returned=1 errno=0 state=error: certificate verify failed
5: Exit status: 5

/etc/foreman_scap_client/config.yaml contains:
:ca_file: ‘/etc/puppetlabs/puppet/ssl/certs/ca.pem’
:host_certificate: ‘/etc/puppetlabs/puppet/ssl/certs/web1.mydomain.com.pem’
:host_private_key: ‘/etc/puppetlabs/puppet/ssl/private_keys/web1.mydomain.com.pem’

I read somewhere in this old redhat portal thread that it might be katello related.
Can anyone spot something obvious here and get me back on the right path?

Thanks again.

I’m keen on following your frustrations and tribulations as it’s only a matter of time before I’d be finding my foot in those bear traps… :yum:

Sooooo, if there is consensus as to “fork”, may I suggest new threads started with headings such as “Getting Started : SCAP” as to signal the branch that thread forks from the Getting Started root ?..

( This is purely to keep my sanity as I try and document the journey. )

The live stream [Deep Dive] PXE booting in a pure IPv6 environment (with Dmitri Dolguikh) on 6 Jul 2017 between @Dmitri_Dolguikh and @Gwmngilfen is what got my attention onto Foreman.

A lot of water has flown under the bridge since I first watched it and I’d need to revisit it again.

Has anyone else gone that route as yet?

Any possible advise or caveats from @Dmitri_Dolguikh?

For the record, Dmitri did some initial reserarch on this but the effort ceased AFAIK.

Dmitri no longer works on Foreman full-time. I wonder about the future of the IPv6 implementation in the netboot package: https://github.com/google/netboot/commits/master/dhcp6 and for this reason I would suggest to focus on integrating with Kea or dnsmasq. The major concern for Satellite team is supportability by Red Hat - currently only dnsmasq is in the base RHEL repository (thus getting full support), Kea is only in EPEL (no official support).

Of course anybody from the community is more than welcome to start working on Kea DHCP module for smart-proxy right away.

1 Like

Thanks again to @mason for the live debugging session last night! You can watch the video here:

Thanks also to @John_Mitsch and @Partha_Aji1for stepping in and helping out :slight_smile:

@mason, @peek, @jmrice6640 I’d still be interested in doing a “New Users panel” video at some point (if we can find a common time), where we discuss experiences and perhaps look at ways to improve - it’s so hard to remind ourselves of where the sharp edges are when you’ve been using Foreman a while, so this would be refreshing to say the least :slight_smile:

2 Likes

Try subscribing your host as a content host and re-running Puppet.

  • Head over to Content -> Activation Keys and create activation key
  • Go to Hosts -> Content Hosts, Register a host button at the top right. You will get steps to run on your host that will register it using the activation key. You do not need to install katello-host-tools or katello-agent to get openscap working.
  • re-run Puppet. The certificate paths should change.

What is the difference between:
puppet module install theforeman-foreman_scap_client

and:
yum install puppet-foreman_scap_client

puppet module install theforeman-foreman_scap_client gets the Puppet module from Puppet forge.
yum install puppet-foreman_scap_client will get the packaged version from our repositories.

1 Like