The installer automatically wants to use the hostname as the Foreman service name.
But in my context, that’s incorrect.
I have registered an “A” record for the hostname, and a “CNAME” for the foreman service name (pointing to the “A” record).
How can I run the installation in a way that it will use the service name (CNAME), rather than the hostname?
Or is there an alternative way, e.g. changing the configuration and certificate post installation?
As we would also like to manage remote systems, I assume that the foreman service will have to be exposed to the internet.
I have too little experience yet with Foreman and Katello in order to give you a valid and complete answer.
However, as a starting point, the CNAME would probably only come into play accessing the web interface as an admin or downloading the content from the registered hosts. This certificate can easily be changed after the installation.
In the global settings you also find the URL of Foreman, however, I do not know if you would need to change that or not, maybe someone has more insight into that matter.
Regarding the exposure to the internet, would it be wise to set up a smart proxy for registration and content distribution and keep the central Foreman server behind a firewall? You could probably more easily harden that proxy and reduce the number of possible attack angles. It would also make sense to have an application proxy in front of that smart proxy, to further limit the exposure. Not sure, just a thought.
Personally I wouldn’t use forklift for production installs. The number of commands you need to run is tiny. Especially when you consider the options you need to pass in.
@rbremer is correct that you will need to override the Foreman URL in various places. I don’t have a complete list, but I’d recommend to go over foreman-installer --full-help. You should find at least --foreman-servername and --foreman-foreman-url. Then there is also --foreman-proxy-foreman-base-url and --puppet-server-foreman-url for connections back to Foreman. That should probably be sufficient.
Yes, I don’t need to expose the admin interface, but registered hosts getting updates is what matters. This is what I was doing with Spacewalk. Is Foreman working differently?
Maybe I need to learn more about Foreman networking architectures. Is the “smart proxy” you are referring to a Foreman role, or would that just be a regular load balancer such as haproxy? I think your suggestions make sense, but I don’t fully understand the implementation.
I will try to find documentation on the subject of Foreman architecture.
I wasn’t even considering not using Forklift. I guess that was the advice I needed. I will rerun the installation in my lab using individual installation commands.
That’s a lot of good advices, I’ll try them and let you know how.
Many thanks!
The smart proxy is basically a content only host, which can also run Ansible roles and Puppet actions etc. You will find a good documentation inside of the Foreman manual.
Coming from Spacewalk this is a quite different architecture, you need to learn about content views, lifecycle environments and smart proxies. Many things are quite identical, from repositories to activation keys etc.
Unfortunately, I haven’t found a really good guide on how to compare Spacewalk and Foreman/Katello or even how to do a guided migration. All I can say is Foreman/Katello is the way to go.
Personally I would avoid this. From an architectural standpoint I still can’t grasp why we would recommend this. As an admin it’s not how I would deploy services. Note that it is very Katello specific. If you don’t use Katello, the whole document is invalid.
There is no good document on it, but IMHO the Foreman setup itself should be HA. Making Smart Proxies HA is not something I would recommend unless you really know what you’re doing. It’d be a long rant on why that’s hard.
@ekohl Thank you for your input here. It’s very interesting to hear that this might be a bad approach. I stumbled over the document a few weeks ago and considered it an official how-to. The setup is definitely difficult and probably has to do with the zero-downtime approach when doing maintenance work on individual servers.
But a simple reverse proxy or application level proxy in front of a smart proxy is something you would consider practical?
It sounds like a reasonable idea.
But in my reality, there is lots of small networks (each protected by their own firewall), and they contain only 2-5 Linux VM’s each, and these should be managed.
Putting a Foreman proxy (i.e. smart proxy) in each network would suddenly make it quite expensive, and we won’t be able to do that.
From an economical point of view, it would be good if all Linux hosts were fetching jobs from a central Foreman/Katello host, preferably using only 1 tcp port. That’s what I did with Spacewalk.
We can live without certain features (e.g. provisioning, discovery), but we need inventory, patching, config management.
Is that still possible with Foreman/Katello?
I wouldn’t mind setting up one extra Foreman proxy for external access as that central host. Would that be beneficial?
I’m not quite sure how to go about the basic architecuture in a way that is economic.
You don’t need to install a smart proxy in each of the small networks. I was suggesting using one smart proxy at your central site inside of your DMZ which is the registration and content delivery host for all your remote sites. The central Foreman server can be located in your internal network and synchronizes its content with the smart proxy.
For patching and config management (I am using Ansbile) the smart proxy (or the Foreman server itself) needs to be able to ssh into each of the VMs in order to execute scripts etc. So you will need to plan for that in your firewall setups. If you just want to download patches from the VM directly, all you need is port 443 to the smart proxy.
No. Reverse proxy with a Smart Proxy is known to be a problem because it breaks authentication. You would essentially be running it without authentication which is a obviously a security disaster. TCP level load balancing can be done, but it highly depends on each module if that would be supported. A module that talks to some REST API on a different host will easily work (dhcp_infoblox), one that uses local files won’t (dhcp_isc).
You should also question why you want HA. The Smart Proxy is mostly a control plane for services. If you can’t make changes, is that really a problem? For example, being unable to create a new DHCP host doesn’t happen that often. Perhaps it’s sufficient to configure the DHCP server itself with a failover so that at least hosts can get leases. That may be simpler and thus easier to maintain.
That’s what I learned in practice: maintaining HA setups can cause many problems and less service uptime than a single service. Weigh the benefits against the risks. Always look for the smallest amount of complexity in your deployment that still satisfies the requirements.
As @rbremer said, a separate Smart Proxy is only needed if the networks need to be isolated. If routing is allowed, you can use a single Smart Proxy. If you run a DHCP server, you need to have one in each network but you can make the Smart Proxy work in multiple subnets. There’s a few options in the installer to make that happen.
Other reasons why you would want a separate one is that you have multiple physical locations (one in NL, one in US) for performance. Even if routing is allowed, the lower latency and bandwidth can be a big benefit.
Thank you for the details Edwoud. It’s a question which always comes up in any kind of http/s setup, wether it can run behind a reverse proxy or not. I think your statement makes that very clear that in the case of Foreman/Katello it should not be considered.
I don’t see how we can configure ssh to each of the remote hosts. The remote networks are exposed each with only one single IP to the internet. We would have to introduce port based NAT rules for each VM on the firewall. (e.g. internetIP:50022 -> VmIP01:22, internetIP:50023 -> VmIP02:22). That’s an ugly mess we would like to avoid by pulling configs and packets from VM’s, rather then pushing them from Foreman. I think that speaks against Ansible?
That sounds promising. Is there a Foreman Client which I can install and configure on remote VM’s (just like with Spacewalk) and tell it to pull in certain time intervals from Foreman/Katello? How does polling on 443 work?
I am not sure if I can answer that as I don’t even know if Foreman could use a different port number for each host to ssh into.
The concept of managing a host is very different from Spacewalk. You cannot just “pull” config files, you need to use Puppet or Ansible, Salt or any other Foreman plugin for managing the host. I only started using Foreman/Katello, so we need others to chime in here.
I know katello-agent is deprecated for version 4, so I never installed it. Would love to hear from some more experienced folks in here to get more details.
As soon as you register your client with subscription-manager the yum repos will be pulled from the smart proxy or foreman server via port 443. But again, that’s not for config files.
That does indeed make Ansible rather painful if you can’t reach it via SSH. Some SSH jump host might help, but not sure it will help you. If you’re looking for a pull based approach then maybe Puppet is a closer match to what you want to achieve?
