Project

Profile

Help

Story #5356

As a user, I can download a configuration for yum/dnf from an RpmDistribution

Added by dkliban@redhat.com over 1 year ago. Updated 6 months ago.

Status:
CLOSED - CURRENTRELEASE
Priority:
Low
Assignee:
-
Sprint/Milestone:
Start date:
Due date:
% Done:

100%

Estimated time:
Platform Release:
Groomed:
No
Sprint Candidate:
No
Tags:
Sprint:
Quarter:

Description

It is common for repositories to include a repo file that can be used to add the repository to a client. This file can be manually placed into /etc/yum.repos.d/ or it can be specified as a parameter to yum/dnf. e.g.

dnf config-manager --add-repo http://example.com/pulp/content/some/repo/path/config.repo

Related issues

Related to Pulp - Story #6570: as a plugin writer, my custom content handler can handle requests for CONTENT_PATH_PREFIX CLOSED - CURRENTRELEASE

<a title="Actions" class="icon-only icon-actions js-contextmenu" href="#">Actions</a>

Associated revisions

Revision b1d7979e View on GitHub
Added by Pieter Lexis 7 months ago

Implement .repo file for RPM repositories

ref #5356

Revision 6a661c86 View on GitHub
Added by Pieter Lexis 7 months ago

Add directory listing for public.key, config.repo

ref #5356

Revision c9c226e1 View on GitHub
Added by Pieter Lexis 7 months ago

Assume the public key is called public.key

ref #5356

Revision 6b3b149f View on GitHub
Added by Pieter Lexis 7 months ago

Add tests for config.repo

closes #5356

Required PR: https://github.com/pulp/pulpcore/pull/678

History

#1 Updated by ttereshc 9 months ago

  • Sprint/Milestone set to Priority items (outside of planned milestones/releases)

#2 Updated by ttereshc 9 months ago

  • Priority changed from Normal to Low

#3 Updated by dkliban@redhat.com 8 months ago

The RpmPublicationSerializer[0] will need to be updated to accept an RpmDistribution as an optional parameter. When such parameter is passed in, the RpmPublicationViewset[1] should pass the distribution's PK to the publish task[2]. The publish task should then create a new Artifact and PublishedArtifact for the config.repo file. The file should contain the URL associated with the RpmDistribution that was passed in by the REST API user. If a SigningService is being used to sign the metadata, config.repo should also contain a path to the public key in the publication.

[0] https://github.com/pulp/pulp_rpm/blob/1383fbf86b19a3baacdd46be1903344f1eb24c25/pulp_rpm/app/serializers.py#L337

[1] https://github.com/pulp/pulp_rpm/blob/1383fbf86b19a3baacdd46be1903344f1eb24c25/pulp_rpm/app/viewsets.py#L228

[2] https://github.com/pulp/pulp_rpm/blob/1383fbf86b19a3baacdd46be1903344f1eb24c25/pulp_rpm/app/tasks/publishing.py#L201

#4 Updated by dkliban@redhat.com 7 months ago

The solution in the previous comment creates severe limitations for the user. Any publication that includes a config.repo file will need to be recreated each time the user wants to use it with a new Distribution. This file should always be dynamically generated when it is requested from the content app. This can be achieved in the following way:

The RPM plugin needs to introduce a new setting to allow users to specify RPM_CONTENT_PATH_PREFIX.

The RPM plugin needs to provide it's own content handler that inherits from pulpcore.app.content.Handler[0]. The new handler should handle a route that looks like this: settings.RPM_CONTENT_PATH_PREFIX + '{path:.+}'. This is a slight variation on what pulpcore already provides[1].

The handler needs to override the _match_and_stream method[3]. This method needs figure the distribution being requested, call permit(), and then check if the path being requested is equal to 'config.repo'. If it is, it should dynamically generate the config file based on the base_url of the distribution and any information about a public key associated with the publication that's associated with the distribution. If the path requested is not config.repo, then it should simply call super().

[0] https://github.com/pulp/pulpcore/blob/master/pulpcore/content/handler.py#L50 [1] https://github.com/pulp/pulpcore/blob/master/pulpcore/content/__init__.py#L51 [2] https://github.com/pulp/pulpcore/blob/master/pulpcore/content/handler.py#L303

#5 Updated by ipanova@redhat.com 7 months ago

makes sense to me, +1

#6 Updated by bmbouter 7 months ago

The proposed plan in Comment 4 would work and with what we have currently it's what I would recommend also. I want to propose an alternative for us to consider too.

What if we did these things?

  1. Add a hook method to BaseDistribution named content_handler() which would provide a no-op as it's base functionality and return None by default. It would take subpath as the single param and that would be the url portion after the distribution's base_path (the remaining part).
  2. In the content app just after the Distribution is matched and permit() is called we have the content app call this new content_handler. That would roughly be here.
  3. If the content_handler(subpath) returns a subclass of aiohttp.web.Response(...) then return that and don't continue to call the rest of the code in the content app.

Then the RpmDistribution would implement content_handler(sub_path) and if sub_path == config.repo it would return the dynamically generated repo file.

The reasoning for this idea is to keep the repo file handout near the repo itself. Users think of the repo as the distribution path, and this would keep them together.

#8 Updated by dkliban@redhat.com 7 months ago

bmbouter That is a great improvement to the design. It removes the need to add a new URL for serving RPM content. @lieter what do you think about opening another PR against pulpcore with this new interface in BaseDistribution and a call to it from the BaseHandler?

#9 Updated by dkliban@redhat.com 7 months ago

  • Subject changed from RpmPublication should include a repo file that clients can use to configure yum/dnf to As a user, I can download a configuration for yum/dnf from an RpmDistribution

#10 Updated by dkliban@redhat.com 7 months ago

I added a story for pulpcore to capture the requirements for that piece of the work.

https://pulp.plan.io/issues/6570

#11 Updated by dkliban@redhat.com 7 months ago

  • Related to Story #6570: as a plugin writer, my custom content handler can handle requests for CONTENT_PATH_PREFIX added

#12 Updated by rchan 7 months ago

  • Status changed from NEW to ASSIGNED

#13 Updated by dkliban@redhat.com 7 months ago

The public key is added to the Publication as PublishedMetadata. It's placed into the 'repodata' directory. I am not sure if that's the right path for this file though.

https://github.com/pulp/pulp_rpm/blob/master/pulp_rpm/app/tasks/publishing.py#L434

#14 Updated by dkliban@redhat.com 7 months ago

The signing service interface is not strong enough and allows creators of signing scripts to generate arbitrary names for public key files. We should improve this interface and enforce that the name of the public key file is public.key.

Until the interface is made stronger, we should document this requirement and the content_handler for RPM distribution should assume that the public key's relative_path is repodata/public.key.

#15 Updated by mdellweg 7 months ago

wrote:

The public key is added to the Publication as PublishedMetadata. It's placed into the 'repodata' directory. I am not sure if that's the right path for this file though.

https://github.com/pulp/pulp_rpm/blob/master/pulp_rpm/app/tasks/publishing.py#L434

You can specify whatever relative_path you desire, when creating the published metadata artifact. (relative_path="repodata/public.key") It should not matter at all what name the signing script chose. Also I believe the public key should be part of the distribution, since you probably do not want to invoke the singing script in the content handler.

#16 Updated by Anonymous 7 months ago

  • Status changed from ASSIGNED to MODIFIED
  • % Done changed from 0 to 100

#17 Updated by ttereshc 6 months ago

  • Sprint/Milestone changed from Priority items (outside of planned milestones/releases) to Pulp RPM 3.4.0

#18 Updated by ttereshc 6 months ago

  • Status changed from MODIFIED to CLOSED - CURRENTRELEASE

Please register to edit this issue

Also available in: Atom PDF