Need Use Case for different installation media for single operating system

While pondering with colleagues about what to do with Set tftp kernel/initrd path depending on installation media (we found a solution in the mean time), I am wondering whether this foreman installation is using Operating Systems and Installation Media correctly.

The Foreman manual is a bit vague about this and leaves the following interpretations:

(1) 1:1 relationship between OS and IM
This is what most sites I have seen using foreman do: Have only a single set of IM per OS. The trivial case, willl obviously work.

(2) use IM to minimize cross-datacenter network traffic
In this use case, one has multiple IMs per OS, with all IMs having the same content but being located at different places (read: “mirror”). This is the version I, after thinking about it, believe to be the indended use. With this setup, one can force installations to always use the most local mirror (by only allowing these with the IM). This also explains why IMs can be restricted to some locations and Operating Systems can’t.

(3) use IM for OS staging
This is what my current customer does (and has always been doing): They do snapshots of the OS repository, have one IM per stage inside a single OS, and advance the code through the stages by renaming snapshots on the repository server. This breaks horribly for installation when different snapshots require different sets of initrd/kernel combo since the latter is selected inside the PXELinux template and is associated by default with the OS, not with the IM.

Since the manual is vague and could use improvement, I would like to file a documentation issue, but not without asking for your input since I might be missing something here. What is the intended use case, what are typical use cases, and what are impractical use cases for having more than one IM for an OS?

I would appreciate your input.


Instead of doco issue, file PR. Really, our documentation needs much more love. I will gladly review such a PR. Anyway: You described the typical use case of IM in case (2) actually, selecting the closest mirror to your datacenter. That is the main purpose.

It is important to understand that IM is a resource for installation repo, not for updates repo. The way Linux provisioning works in Red Hat / Fedora world (and most others) is based around two repositories. There is one repository which is often called base, install or kickstart. It holds installation program (kernel/ramdisk) and packages which are “frozen” at certain time, typically when the version of OS is released. They don’t get updates at all. The same content is on CD/DVD ISO images when you download the Linux OS in this format.

In addition to installation repo (we really like to say “kickstart tree”), you have updates repo where package updates are being pushed. Typically, your Linux clients are subscribed to both. This is how it works in most Linux distributions, you have at least two repos: base and updates. Installation Media is just the base repository usually, not the one which holds the updates.

Therefore if you do snapshots of repos (which is a good approach indeed), you do this with updates repositories and not with IM. You only add IM when new version comes out, mirror it to your datacenters (and make a pick when installing an OS), but then it stays unchanged. Snapshots for IM is not relly necessary.

There are however exeptions, in RH world installer repo gets a “refresh” from time to time, when there is some very important bug in the installer itself. This is quite rare tho. To be fair, some users and Red Hat customers opt-in to filter out all unnecessary packages, typically in highly-secure deployments. For this, you need a copy of installation repository but with all unnecessary packages filtered out. Then this would be another IM entry in Foreman.

I suggest to stick with two repositories approach with unchaged base repo. To achieve this, customize your provision template type and point your “updates” repo to the desired location (snapshot, stage). This can be easily done with host parameters (hostgroup as well), or via configuration mgmt tool if you prefer. It is just a URL at the end of the day.

Consider trying out Katello plugin which allows advanced content management for Yum and other types (Suse has been merged upstream into Pulp project recently if you use that). With Katello, you can do things like package filtering or promotions with a single click. Katello basically “disables” IM and uses own concept of “Synced content” resource. It only works with RH at the moment. There is also a product by ATIX, which does the same for Suse content, if I am not mistaken.

Hope it helps.

Hi Lukas,

thanks for helping.

Which repository is the manual in? In the foreman git, there is nothing matching “manual”.

That is what I reckoned after pondering. Thanks for the clarification.

Yes, but those differ when you go from 7.x to 7.x+1. Which is what happened in the “dev” stage at our site last week and broke things. People say that’s what they’ve been doing for years, and this is the first time it broke.

… unless a new OS release happens. “We” have only one OS “CentOS” and do the version updates by moving the snapshots through the stages. I think this has been broken for years. I only noticed that last week.

I am not sure whether I can use the CentOS 7.2 installer to install a 7.4 OS. Even if I was sure, I wouldn’t want to do that.

Will Katello some time in the future replace the OS/IM mechanism? I don’t think that “we” are ready for a migration this big yet.

It does, thanks!


1 Like see the README there which explains how to build site and file PRs.

I am not sure I follow your comments above, but let me comment on this statement. You can indeed install CentOS 7.2 and then have it upgraded to 7.4. Some users prefer highly “locked” environments and don’t upgrade too much, only manually picked errata. So this is real life workflow for some, might not be good fit to you, sure that is fine. This is by the way what Red Hat customers pay for (EUS channels - ability to “stay” on let’s say RHEL 7.2 for a longer period of time and “skip” few releases to save money with ugprading).

Anyway, here is a wrap up. This is a kickstart tree (thus installation media): (older versions like 7.3 are now moved to but still available there). You basically mirror this once and set installation media.

Beware that CentOS mirrors publish a symlink here but what you see is really this: and I do not recommend to use this URL for installation media as it is being changed after each release.

The repository you want to manage content for is and it is continious yum repo with all the updates across various CentOS releases.

The way it is implemented today is that Katello overrides IM and provides own URL there, OS is still needed and it is automatically created when you sync a “kickstart tree” repository. I think this works fine, proposals for improvement would be nice.

Thanks for the explanation. I have put this issue up locally for the next face-lift step on the infrastructure, but for the time being site personnel needs to be extra careful to not trip over the wires they have strung themselves in. Thanks for the explanation, this was a great help in understanding how things are supposed to be.

Nice to see others pondering over this as well. Combined with alternative architectures and OS “flavors” I find this tricky to work with. Consider the following OS’es defined in Foreman;

CentOS 7.4.1708
Ubuntu 16.04 LTS

Add multiple architectures for each of these, including x86_64, aarch64 & i386 and associate all these architectures with both of the operating systems. Both CentOS and Ubuntu have separate repos for altarch & ports, respectively, which means that you will need minimum 2 IM’s per OS;

IM CentOS 7 x86_64 :$major.$minor/os/$arch
IM CentOS 7 aarch64 & i386 :$major.minor/os/$arch

IM Ubuntu 16.04 amd64 & i386 :
IM Ubuntu 16.04 aarch64 :

It’s possible to go wrong here as there is no way to define the relationship between architecture and IM. Foreman will present both IM’s and one of them won’t work. Obv naming them as above helps avoid mistakes but the point is you pick the architecture for the OS but that does not translate to the IM in any way I can see.

To further complicate things, Canonical also have the “HWE” flavor and the pxe files lives in the “release-updates” repository and the hard-coded tftp path in Foreman does not match. The only way to fix this that we’ve found is to have a separate OS that use “release-updates” and modify Foreman code to fetch the correct tftp bootfiles based on the release flavor.

Debian seems to be the least troublesome OS to deal with in this context. A single OS for major versions, multiple architectures and single IM seem to work fine.


Thanks for the writeup, that is indeed an issue. Workarounds include creating separate IM or syncing repositories into consistent tree. I created a ticket:

Patches welcomed! :slight_smile: