Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add os product tag based on /etc/os-release #3188

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

sbernhard
Copy link
Contributor

Currently, content filter based on the product-tags only works for RHEL. The content filter method should also be usable for other OSses, like CentOS, SuSE or even Debian/Ubuntu. With this approach, a [os-name]-[os-version] tag is created based on /etc/os-release. The tag is only generated and added if the feature is activated by setting use_os_release_product=1 in /etc/rhsm/rhsm.conf

@sbernhard sbernhard force-pushed the add_os_product_tag branch 5 times, most recently from b997319 to 234c4da Compare December 20, 2022 16:17
Currently, content filter based on the product-tags only works for RHEL.
The content filter method should also be usable for other OSses, like
CentOS, SuSE or even Debian/Ubuntu. With this approach, a
[os-name]-[os-version] tag is created based on /etc/os-release. The tag
is only generated and added if the feature is activated by setting
use_os_release_product=1 in /etc/rhsm/rhsm.conf
@ptoscano
Copy link
Contributor

Just to recap this what was discussed on IRC some days ago.

This came as a request to make automatic attaching of products in SCA mode work also OOTB in non-RHEL distributions:
https://community.theforeman.org/t/rfc-making-things-easier-when-working-with-custom-products-simple-content-access-sca/31334

The problem happens because non-RHEL distros do not have product certificates in /etc/pki/product-default/; a possibility here is to get the product certificates from Candlepin:
https://petstore.swagger.io/?url=https://raw.githubusercontent.com/candlepin/candlepin/master/api/candlepin-api-spec.yaml#/owner_product/getProductCertificateByOwner

An example is done by the importer of the test data of Candlepin:
https://github.com/candlepin/candlepin/blob/ba4bee64d189296d1c94fa4b111512fd6308f53d/bin/deployment/test_data_importer.py#L589-L617
and I know this kind of works because it is used when testing e.g. the Cockpit plugin of subscription-manager.

@sbernhard
Copy link
Contributor Author

Regarding the product certificate, it does not contain Tags/Brand Name/etc because the product was created by Katello:

Product:
	ID: 162245039429
	Name: AlmaLinux Client
	Version: 
	Arch: ALL
	Tags: 
	Brand Type: 
	Brand Name: 

This product is managed via katello. so the question is, how to set Tags, Version, Arch, etc.

@jeremylenz
Copy link

Hey @sbernhard

In Katello/katello#8983 we started adding requiredTags to product contents; see https://github.com/Katello/katello/pull/8983/files#diff-1d9610ad658156e6a608276963e086bc1670cb8fbd7491e48e5fddee20e3cd94

I think you could modify arches etc. in the same sort of way. Basically we added the params to the Dynflow action and those get passed into ::Katello::Resources::Candlepin::Content.create which calls the Candlepin API.

hopefully this gets you started :)

@sbernhard
Copy link
Contributor Author

First of all, thanks for your comment. Would be nice to continue this discussion.
The idea was to be able to use the required_tags for "non-RHEL" products.
Pino mentioned, that its possible to download the product certificate from candlepin and then store it in /etc/pki/....
If these certificates would contain the "product-tags" (like suse_15.2) it would be possible to match these tags.
But, currently, the downloaded certificates don't contain the product-tags because katello doesn't set them (of course)

The idea would be:

  1. set the product tag for custom products
  2. download the cert during provisioning on the managed host
  3. check for provided-tag & required-tag during subscription-manger usage (based on the "uploaded cert")

@jirihnidek
Copy link
Contributor

jirihnidek commented Mar 15, 2023

Thanks for this PR. I like the idea. 👍 It seems like a simple change, but it could actually have deep impact on our flow.

We do lot of things with tags and to be honest I don't understand many of them. We will have to discuss this topic in our team more and then we will let you know the outcome of this discussion.

@sbernhard
Copy link
Contributor Author

sbernhard commented Mar 15, 2023

Thanks @jirihnidek
To summarize the use-case

  1. With this change a auto-generated tag would be generated based on /etc/os-release
  2. This product-tag is then used to match content-tags. If they match, this content (=this repo) can be used on sub-man
  3. In katello, content (=repos) can be created which are only valid for certain OS - and this is stored as content-tag

Therefore, this addition would make it possible to use OS-specific repos for other than RHEL OS because currently, only RHEL is possible to be a product-tag.

@sbernhard
Copy link
Contributor Author

How can we proceed with this?
@ptoscano / @jeremylenz / @jirihnidek

@jeremylenz
Copy link

I feel like after custom products' default enablement is changed to disabled (Katello/katello#10502), the need for OS restrictions is eased significantly. But if y'all decide this is feasible in sub-man I'm happy to continue the conversation.

@jirihnidek
Copy link
Contributor

@sbernhard Hi, still discussing about this with many folks...

Would it be useful to get tool for creating product certs with tags?

BTW: Tags in product certs are also used for getting release file from CDN.

@sbernhard
Copy link
Contributor Author

We tried to add the functionality to candlepin, but this was rejected: candlepin/candlepin#3794

The overall goal is to filter repositories based on the OS name. Currently this is done by the product tags which candlepin/sub-man are using in their certs. As we can not extend this currently, it would be possible to use this PR to check if certain repos can be used based on the currently running OS.

How can we proceed with this PR @jirihnidek / @ptoscano / @jeremylenz ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants