I’m trying to build a Chef Server to run inside Docker and am facing some challenges with the fqdn.
The problem can be generalized to any time Chef Server is behind a NAT.
The problem is Chef Server currently requires the fqdn to be set in /etc/chef-server.rb before running reconfigure.
I finally found the configuration that works here
However a server behind a NAT has two names, one facing outside and one facing inside.
Why do we need to hardcode the fqdn in the first place?
Why can we simply use whatever the host name is coming from the http requests?
That way the overall configuration is simplified and Chef Server would just work for all clients inside and outside the NAT.
However a server behind a NAT has two names, one facing outside and one facing inside.
Why do we need to hardcode the fqdn in the first place?
Why can we simply use whatever the host name is coming from the http requests?
That way the overall configuration is simplified and Chef Server would just work for all clients inside and outside the NAT.
—ming
Note that in addition to the problem you cited above, there’s an issue with being able to verify a server’s certificate. Chef client currently doesn’t verify certificates by default but this is something we’re working to actively change as soon as we can while causing the minimum disruption. Part of certificate verification is checking that the hostname encoded in the certificate (CN) matches the hostname the client makes the request to. So it’s best if you can find a way to configure the server with the hostname that will be used from the outside, if you plan to use this in production in any capacity.