Hi @evgeni
Thank you for a fast reply, we arent really using many plugins - pretty basic config (and old setup taken over)
we wish to start from scratch, but its a 200 vm install so id rather do some proper homework on my options before initiating anything
so if we want to go for a home run i hear you say it would be feasble to start a new install and reregistering nodes
Is there a way to migrate classes ( i guess only data migration here is to dump the postgree sql and reimport)
Yeah, there is not really a good way to migrate parts of the setup over. DB might have a lot of cross-table references which will be hard to untangle w/o breaking stuff.
(Well, you could have them externally in an Ansible playbook or so, so that could be replayed, but this doesn’t sound like it’s a case for your setup).
@evgeni is there more documentation of how to call external ansible playbooks when the server is done with deployment
Back to original topic - so what i hear you say and which would be the proper recommended path with least issues - new server + new config and manual recreate classes etc and reregistering hosts and put back into the group?
after that we can do or consider next step approach to switch to ansible.
I might have talked about this topic last FOSDEM 
We have Ansible modules that help you set up your environment, have a look at Foreman Ansible Modules documentation index.
Yes, that’d be the cleanest and best supported way, if you want a new setup.
What I’d do in this situation is the following:
)Shameless plug: I have some code on github that might help you on your way:
What sounds so simple is actually a pretty huge task, in particular if you don’t use simple content access, as you have to set up all subscriptions and repository sets for all hosts to match what you had before…
Compare Foreman Ansible Modules - subscriptions and repo overrides of content hosts
Thats an really intersting approach - will have to read up on it.
Thank you for all your help - and must have missed that talk hehe!
Sorry, I didn’t mean to imply that setting up Foreman with Ansible is a trivial task, I think I sunk about 300 hours in developing and testing that role. However, all that work does pay off now, as I have reduced the time to deploy to 45 min + sync. Which most of the times completely removes the need for backups at all.
As most of the information in Foreman (in the way we utilize it) can be either stored outside of Foreman itself (e.g. DHCP information in Infoblox/Netbox) and we don’t care enough about repo state to warrent backups.
To elaborate on that last point, we use Foreman/Satellite to perform controlled updates on systems. Should we have to do a disaster recovery on our setup, we ‘just’ restart the cycle (and bring DEV up to date with whatever gets synced).
And (Simple Content Access) SCA mode or not doesn’t really matter, though Red Hat is moving forward with making Satellite subscriptions SCA by default. I actually added support for SCA later when I got a subscription manifest from RH that had SCA enabled (which I didn’t see) 
So the role takes all of the required magic in account (as far as I ran into it or needed it)
Anyway, I sincerely think it might help you and if you miss a feature or spot a bug, I’m happy to assist
EDIT: I’ve deployed multiple Foreman instances for multiple customers and because of all the automation, they are all lookalikes of each other. Which saves me and my team a lot of time getting ‘acquainted’ with the environment
i do get the point of automation of the automation approach - we are trying to install a new foreman from scratch which is kind of painfull just to speak of the ssl issues by defining a cert to communication.
So this ansible playbook does it install a complete foreman ?
It does, it leverages the Foreman Operations Collections to set up repositories and kick off the installer with some options.
The role will install Foreman 3.1 / Katello 4.3 as of now, but that’s only because I haven’t come around to test Foreman 3.2/ Katello 4.4 yet. It should work just fine if nothing breaking changed
Afterwards you can go ham on defining the required config.
Does it take into account with ssl ?
Depends, Foreman/Katello brings it’s own CA, so it will generate a self-signed CA and a certificate to set up the Web UI, if that’s acceptable in your environment, yes.
If you want to add your own TLS certs for the WebUI, the role currently doesn’t support it. But the foreman-installer does.
Just look into my thread I have linked above: it’s not possible to add subscriptions to content hosts nor to define the repository overrides for the content host. So even if I extract the information from my current foreman server, I cannot use the ansible collection to configure the hosts on the new server.
It depends a bit on your situation, but do you have a lot of different configurations in your environment? Or would it be possible to abstract it a bit by dividing them into groups? If that’s possible (and even a lot of groups should be no issue) you could look into Activation keys.
Those will set up granular access to the repositories you determine. And further configuration can be made using Ansible modules for Subscription Manager, such as community.general.redhat_subscription if I’m not mistaken.
As mentioned in that other thread, anything beyond the basic activation key I am using when registering new hosts, is client dependent. People need different software, different repos and chose it individually for each host as we are trying to avoid using external repos. Just the postgresql repos include versions 10 to 14 and quite a few hosts are using postgresql but with different versions.
Worse: it’s quite a dynamic configuration which basically means I need an automated process to extract the information from the old foreman server, quickly import it into the new server and then quickly do the migration because I cannot tell people not to make subscription/override changes for a couple of days.
And manually migrating hundreds of clients is not an option either.
So I guess in the end I will end up with a shell script I write myself which extracts all active subscriptions and repo overrides using subscription manager on the client, then connect it to the new server and reestablish everything. So far I think that’s the easiest way.
And as I have mentioned elsewhere already a couple of time: the biggest deficit of the ansible collection when using it for migration is the extraction tool: the tool which goes through an existing foreman server writing a playbook to recreate the same objects on a new server. Currently, I basically extract the information from the database on the old server (because I know my SQL and but no python) and put it into playbook form. And even though that way I was able to quite quickly recreate all my 30+ products with 120+ repos, it was still cumbersome. All the information is there on the old server but you do wonder why it’s so difficult to get it in a form to process it…
And to make things worse: while the Foreman (non-Katello/non content) parts may be quite static, the content parts are not. Just take the foreman/repositories which need to be added for every minor version. So basically, while putting everything together in my ansible playbook I must match all changes I am still making on my old server into the playbook.
So while the idea sounds simply it’s really not so simple if you want to migrate a production server to a new host…
On registering hosts against a new foreman install: how does one associate a host with a compute resource?
Hi all,
we decided to start a new foreman deploy from scratch - but oh boy we are struggling with the ssl configuration
I get that people need different software, but should they not have access to certain software through the Foreman server? E.g. you create an Activation key with all kinds of developer tools and leave it the the users to enable the repositories they need using subscription-manager.
But you’re right, green fields are easy, though I did sacrifice some flexibility by wrapping it all in the same kind of ‘package’. However, I feel that, so far, the pros outweigh the cons. But it really depends on the situation
Can you elaborate what you wish to accomplish? Are you installing Katello with an external CA, or do you wish to install a custom SSL certificate for the WebUI?
As I’ve mentioned ealier, Katello brings it’s own CA through Candlepin, so unless you need something specific, OotB it will ‘just’ work with a self-signed certificate