Hi Saurabh,
You have got the right general idea, though I believe you will want to skip the steps #3 and #6.
Whether the self-registered deployment still works or is supported (I believe the answer is “no”, or at least “this is not the recommended approach”, though someone may correct me if I am wrong) you will likely have an much easier experience with Katello that is registered to RHSM and has the operating system patched directly from the Red Hat CDN.
At least one obstacle to making the self-registered deployment a good experience was difficulty in getting the katello-agent to work reliably on Katello server itself. There is a plan to replace katello-agent with a REX pull provider (RFC: REX pull provider) but it’s possible there are other issues with a self-registered setup as I don’t think it’s something that we test much or at all.
If your use case absolutely requires an offline/air-gapped environment where Katello doesn’t have access to the RHSM and the Red Hat CDN, then in theory you could still use the offline registration method (https://access.redhat.com/solutions/3121571) and one of the recommended (by Red Hat) offline patching methods (https://access.redhat.com/solutions/29269) for Katello server. Syncing repositories in this use case is a much more complicated process which involves using a 2nd online Katello instance for syncing, exporting the synced data to ISOs, and transferring the exported ISO across the air gap to the disconnected environment, and configuring the offline Katello instance to sync from those mounted ISOs. I have not personally tried this process with upstream Katello and I’m not aware if there would be any differences to the process vs. downstream Satellite.
Kind regards,
William