<div dir="ltr">Great point, Simon. Thank you for sharing that.</div><div class="gmail_extra"> <div class="gmail_quote">On Thu, Dec 21, 2017 at 8:26 AM, Simon Baatz <<a href="mailto:gmbnomis@gmail.com" target="_blank">gmbnomis@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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://[^/]+" "<a href="https://localhost:9443" rel="noreferrer" target="_blank">https://localhost:9443</a>" 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 <a href="http://127.0.0.1:5000/busybox:latest" rel="noreferrer" target="_blank">127.0.0.1:5000/busybox:latest</a> Trying to pull repository <a href="http://127.0.0.1:5000/busybox" rel="noreferrer" target="_blank">127.0.0.1:5000/busybox</a> ... Get <a href="https://default-bento-centos-74.vagrantup.com/pulp/docker/v2/busybox/manifests/list/latest" rel="noreferrer" target="_blank">https://default-bento-centos-74.vagrantup.com/pulp/docker/v2/busybox/manifests/list/latest</a>: Not Found Using the cofiguration from above, you get: $ docker pull <a href="http://127.0.0.1:5000/busybox:1.27.0-glibc" rel="noreferrer" target="_blank">127.0.0.1:5000/busybox:1.27.0-glibc</a> Trying to pull repository <a href="http://127.0.0.1:5000/busybox" rel="noreferrer" target="_blank">127.0.0.1:5000/busybox</a> ... sha256:ebeb530823bf0f229b2e2559a1ea92298d7f1ce2efabd9030c5d2b1deac83af6: Pulling from <a href="http://127.0.0.1:5000/busybox 02b2b239e358" rel="noreferrer" target="_blank">127.0.0.1:5000/busybox 02b2b239e358</a>: Pull complete - Simon > On Wed, Dec 13, 2017 at 11:29 AM, Mihai Ibanescu <div><div class="h5">> <[1]<a href="mailto:mihai.ibanescu@gmail.com">mihai.ibanescu@gmail.com</a>> 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 </div></div>> [2]<a href="mailto:Pulp-dev@redhat.com">Pulp-dev@redhat.com</a> > [3]<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a> > > References > > 1. mailto:<a href="mailto:mihai.ibanescu@gmail.com">mihai.ibanescu@gmail.com</a> > 2. mailto:<a href="mailto:Pulp-dev@redhat.com">Pulp-dev@redhat.com</a> > 3. <a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a> <div class="HOEnZb"><div class="h5"> > _______________________________________________ > Pulp-dev mailing list > <a href="mailto:Pulp-dev@redhat.com">Pulp-dev@redhat.com</a> > <a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a> </div></div></blockquote></div> </div>