Getting Started

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.

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

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:
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:
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/’
:host_private_key: ‘/etc/puppetlabs/puppet/ssl/private_keys/’

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: 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:


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

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

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 …

Is there OpenSCAP support for Debian 9?

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 … :thinking:

I’m in the Pacific timezone (Los Angeles), but I have been known to keep odd hours …

We both currently got sun, only I’m one day ahead of ya ! :stuck_out_tongue_winking_eye:

What’s the weather like tomorrow?

32C sunny skies

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.

How many potholes do you foresee ?

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.

Oh many, I haven’t tried this myself, I have never seen this in action too.

Honestly, extending dnsmasq DHCP providers for IPv6 should be possible if you are willing to swap ISC DHCP with more modern dnsmasq:

But core API needs to be changed. It’s a lot of work.

First hurdle being production implementation. Thereafter I’d be able to through more resources at it. As you’re surely aware, IPv6 is high on my list.