[Pulp-dev] Crane redirects - internal and external content

[Mihai Ibanescu]

Great point, Simon. Thank you for sharing that.

On Thu, Dec 21, 2017 at 8:26 AM, Simon Baatz <gmbnomis at gmail.com> wrote:

> On Tue, Dec 19, 2017 at 12:41:08PM -0500, Dennis Kliban wrote:
> >    Crane cannot perform a rewrite of the redirect URL at this time. This
> >    seems like a reasonable feature request. I recommend filing a story -
> >    we can discuss the feature details on there.
> >
>
> That would be a nice feature indeed.  In the meantime, you could try
> to let Apache rewrite the "Location" header used for redirection
> (using the mod_headers module in Apache 2.4).
>
> We did not fully test this (let alone use it in production), but for
> a test setup with Pulp & crane running in a VM and port forwardings
> (Host 5000 -> VM 5000, Host 9443 -> VM 443), we can 'docker pull' on
> the host from crane using the following Apache config:
>
> <VirtualHost *:5000>
>     Header edit Location "^https://[^/]+" "https://localhost:9443"
>     WSGIScriptAlias / /usr/share/crane/crane.wsgi
>     <Location /crane>
>         Require host localhost
>     </Location>
>     <Directory /usr/share/crane/>
>         Require all granted
>     </Directory>
> </VirtualHost>
>
> For example, without changing "Location", you would get this on
> the host:
>
> $ docker pull 127.0.0.1:5000/busybox:latest
> Trying to pull repository 127.0.0.1:5000/busybox ...
> Get https://default-bento-centos-74.vagrantup.com/pulp/docker/
> v2/busybox/manifests/list/latest: Not Found
>
> Using the cofiguration from above, you get:
>
> $ docker pull 127.0.0.1:5000/busybox:1.27.0-glibc
> Trying to pull repository 127.0.0.1:5000/busybox ...
> sha256:ebeb530823bf0f229b2e2559a1ea92298d7f1ce2efabd9030c5d2b1deac83af6:
> Pulling from 127.0.0.1:5000/busybox
> 02b2b239e358: Pull complete
>
>
> - Simon
>
>
> >    On Wed, Dec 13, 2017 at 11:29 AM, Mihai Ibanescu
> >    <[1]mihai.ibanescu at gmail.com> wrote:
> >
> >    Hi,
> >    In our current setup, we have a purely internal pulp deployment, that
> >    publishes to an NFS share.
> >    HTTP frontend machines handle the cert-based authn/authz and serve the
> >    content from the NFS share.
> >    We have an internal set of HTTP frontend machines, and an internal
> >    customer has access to published content for all development stages
> >    (dev/test/prod).
> >    We also have an external set of HTTP frontend machines, that handle
> >    external customer requests, and only serve the prod stage. Content
> from
> >    the internal NFS share is selectively rsynced into the external disk
> >    share.
> >    This all works great for rpm and such.
> >    I believe there is a problem with docker. We would have one internal
> >    and one external crane deployment, as expected. Content would be
> >    rsynced, as usual. However, because the redirect URL is "baked" into
> >    the redirect json files, the external Crane would redirect to the
> >    internal system, which is not helpful.
> >    We would prefer not to republish / recreate the redirect files in our
> >    transition from internal to external content.
> >    One way to handle this would be a Crane configuration option that
> >    directs crane to rewrite the redirect URL. In that case, internal and
> >    external crane systems would be configured differently.
> >    The questions:
> >    * Is there such an option in Crane? (looking at the code, I believe
> the
> >    answer is no)
> >    * Is there a feature request for something like this already?
> >    * If not, do you agree what I've described above is a valid customer
> >    use case, and should I file it as a feature request?
> >    Thanks!
> >    Mihai
> >
> >      _______________________________________________
> >      Pulp-dev mailing list
> >      [2]Pulp-dev at redhat.com
> >      [3]https://www.redhat.com/mailman/listinfo/pulp-dev
> >
> > References
> >
> >    1. mailto:mihai.ibanescu at gmail.com
> >    2. mailto:Pulp-dev at redhat.com
> >    3. https://www.redhat.com/mailman/listinfo/pulp-dev
>
> > _______________________________________________
> > Pulp-dev mailing list
> > Pulp-dev at redhat.com
> > https://www.redhat.com/mailman/listinfo/pulp-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20171221/2c6270d1/attachment.htm>