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.
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.
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
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.
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?
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…
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. )
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.
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
@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
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.
Thank you, Ondrej. Works as promised.
But now I have a bunch of hosts that need remediation. (I used the PCI policy.)
The reports provide Remediation Shell Scripts.
I am assuming that there is a way to have them run at scan time? Auto-run?
I’m sure a lot of this could be done via puppet, but that seems like a lot of work.
Perhaps someone has already done all of the heavy lifting. No need to reinvent that wheel …
Shhhh . . . Don’t tell anyone, but this actually becoming fun.
I downloaded the scap-workbench on my desktop and created a Tailoring File.
Once I figured out that I needed to run the puppet agent again to push out the new SCAP content,
the scan produced the customized report. This might not sound like much progress,
but the pieces are beginning to fit together, and it’s making more sense. The fog is lifting . . .
I was pondering a moment ago the idea of “online workshop session(s)” ? No recording. No specific time restriction.
In addition, advising the component to be addressed, say OpenSCAP, a week or two before the session as to allow all to digest the available documentation and try it out first.
Only time zones being the biggest hurdle. Which has me contemplate weekends …
Ahh, summer down under.
Seriously, I would be up for some online workshops, as long as we have someone who can actually answer questions. I know both of us will be on the asking side.
Until then, would the current best practice be a DHCPv4 / TFTP smart-proxy on the remote subnet as to provide the new host with a private IPv4 address, although being provisioned dual-stacked.
With the A & AAAA records being recorded in DNS the remote TFTP then provides iPXE to the new host.
iPXE references an HTTPS URL resolving to IPv6 to acquire the image to boot.
In essence, iPXE is not transferred over the public net and though the image is transported over the public net, it is via encrypted IPv6.
Regarding remediation, we do not have that automated yet. Probably the easiest way to fix the failing rules is to take the remediation scripts and use remote execution plugin to run it on the target hosts. I would like to have much better solution in the future.
According to openscap docs, the scanner can be installed on Debian, so we would need to package foreman_scap_client for Debian and test it works as expected.
