I dont' know much about the provisioning aspect of foreman but it seems the following URL works great when foreman is on the same network.

http://foreman:3000/unattended/built (IP is inspected to verify build was successful)

However, in situations where NAT is used I think we should be relying on a url scheme rather than inspected IP packets.
This method would allow for any system in any network to send the built ack to foreman with worrying about NAT.

http://foreman:3000/unattended/fqdn/built

Corey Osman wrote:

However, in situations where NAT is used I think we should be relying on a url scheme rather than inspected IP packets.
This method would allow for any system in any network to send the built ack to foreman with worrying about NAT.

My main concern here is security... since this is a non authenticated call.

I'm more then open for suggestion of how to identify the requesting machine...

Following the same line as suggested in #969 - Direct Client->Foreman communication shouldn't be needed (and moved to the Proxy)

We would have to figure out exactly how, but the client server should never really need to contact Foreman directly (I want to have my Foreman firewalled) and IMHO this "Built acknoledgement" should also be moved to the proxy .

well i would do something like this: wget -q -O /dev/null --no-check-certificate https://foreman/unattended/built/$UUID
where $UUID is a random string shared with the client at the time the provision file is generated. So in the provision file the wget -q -O /dev/null --no-check-certificate https://foreman/unattended/built/$UUID line would be unique each time.

This would help with not relying on a specific IP to be present and instead a hard coded Mac address and UUID.

we can simply use a unique secure uuid to identify the system, very similar to how puppet certnames work.